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Foreword 



This Technical Specification has been produced by the 3GPP. 

The contents of the present document are subject to continuing work within the TSG and may change following formal 
TSG approval. Should the TSG modify the contents of this TS, it will be re-released by the TSG with an identifying 
change of release date and an increase in version number as follows: 

Version 3.y.z 

where: 

X the first digit: 

1 presented to TSG for information; 

2 presented to TSG for approval; 

3 Indicates TSG approved document under change control. 

y the second digit is incremented for all changes of substance, i.e. technical enhancements, corrections, updates, etc. 
z the third digit is incremented when editorial only changes have been incorporated in the specification; 
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Scope 



The present document covers issues related to the evolution of the GSM platform towards UMTS with the overall goal 
of fulfilling the UMTS service requirements, the support of the UMTS role model, support of roaming and support of 
new functionality, signalling systems and interfaces. 
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3 Definitions and abbreviations 

3.1 Definitions 

Editors note : Reference to Definition document required. 

For the purposes of the present document, the [following] terms and definitions [given in ... and the following] apply. 

<defined term>: <definition>. 
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example: text used to clarify abstract rules by applying them literally. 

3.2 Abbreviations 

For the purposes of the present document, the following abbreviations apply: 
<ACRONYM> <Explanation> 

4 Working assumptions 

Information flows provided in this document are for information only. They do not constrain implementation. 

4.1 General 

The phase 1 UMTS/Release '99 GSM standards should provide the capability to support: 

• a core network based on an evolved 2G MSC and an evolved SGSN 

• an optionally evolved Gs interface 

• Mobile IPv4 with Foreign Agent care-of addresses to end users over the UMTS/GPRS network, where the FA is 
located in the GGSN. 

• class A GSM' mobiles. 

• Transcoder location shall be according to 23.930 

• UMTS/IMT2000 Phase 1 (Release 99) network architecture and standards shall allow the operator to choose 
between Integrated and Separated core networks for transmission (including L2) 

• The UMTS standard shall allow for both separated and combined MSC/VLR and SGSN configurations. 

• The UE shall be able to handle separated or combined MSCs and SGSNs. 

• There can be several user planes to these CN nodes. 
The following general concepts should be followed: 

• Separate the layer 3 control signalling from the layer 2 transport discussion (do not optimise layer 3 for one layer 
2 technology). 

• MSC-MSC layer 3 call control is out of scope of standardisation in SMG. 

• As future evolution may lead to the migration of some services from the CS-domain to the PS-domain without 
changes to the associated higher-layer protocols or functions. UMTS release 99 shall provide the flexibility to do 
this in a way that is backwards compatible with release 99 UEs provided this does not introduce significant new 
complexity or requirements in the system. 

4.2 lu Interface 

• Transport protocol across the lu interface for UTRAN shall be according to 23.930 

• The UTRAN shall support two logically separate signalling flows via lu to combined or separate network nodes 
of different types (MSC and SGSN). 

• The UTRAN shall contain a "domain distribution function" to route transparent application-level control 
signalling from the UE to the correct core network domain. The UE shall indicate the type of application being 
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addressed (eg via a protocol discriminator). The UTRAN shall map this on to the correct lu instance to forward 
the signalling. 

• UTRAN-services (including radio access bearers) shall be independent from the core network domain used to 
access them. Either core network domain can access any appropriate UTRAN-service (eg it should be possible to 
access a "speech" radio access bearer from the PS-domain). 

• The protocol architecture for the User Plane of the lu interface towards the IP domain shall be based on the same 
principles as for the (evolved) Gn interface, i.e. the user plane part of GTP over UDP/IP shall be used for 
tunneling of end user data packets over the lu interface. If the lu data transport bases on ATM PVCs then the lu 
IP layer provides the lu network layer services, e.g. routing, addressing, load sharing and redundancy. In this 
case an IP network may be configured to transfer lu data units between RNSs and 3G-SGSNs. 

• One or several AAL5/ATM Permanent VCs may be used as the common layer 2 resources between the UTRAN 
and the IP domain' of the CN. The reason for usage of several permanent AAL5/ATM VCs may e.g. be for load 
sharing and redundancy. It is also possible to use one switched VC per user flow (PDP context or radio access 
bearer). Switched VCs may be used, however the standardization of the procedures and protocols for use of 
Switched VCs is outside the scope of the 3GPP. If operators use switched VC, the specification of procedures 
and protocol for switched VCs are up to operators and out of scope of the UMTS/IMT-2000 specification. 



GTP 
User plane 






GTP 
User plane 






UDP/IP 


UDP/IP 






AAL5 


AAL5 






ATM 




ATM 







lu-PS 



Figure 4-1 : Protocol Architecture for the lu user plane towards the IP domain 

• Charging functionality is located at the 3G-SGSN. On the other hand, only RNC can identify the actual packet 
volume successfully transferred to a UE. In order for 3G-SGSN to provide the volume based charging for IP 
domain, the standard shall support the following procedures over lu interface. 

• The RNC indicates the volume of all not transferred downlink data (discarded or forwarded to 2G-SGSN) to the 
3G-SGSN so that the 3G-SGSN can correct its counter. Partially transferred packets are handled as not 
transferred. 

• The RNC delivers to the 3G-SGSN the discarded or forwarded volume accumulated over an implementation 
dependent time and not per discarded or forwarded packet. 

• The 3G-SGSN can ask the RNC to provide the volume of buffered downlink data to correct its counter at any 
time the 3G-SGSN wants. 

4.2.1 lu Control Plane 

For transport of RANAP messages over lu an SCCP protocol shall be used for both packet and circuit switched 
domains. The SCCP protocol shall fully comply with ITU-T white book. RANAP protocol shall be designed to use this 
service according to the ITU-T standard. lu shall be designed so that RANAP is not impacted by alternatives for SCCP 
message transport on layers below SCCP. 

In the circuit switched domain SCCP messages shall be transported on a broadband SS7 stack comprising MTP3b on 
top of S AAL-NNI. In this domain no other alternatives are standardised in release 99. 

In the packet switched domain the UMTS standard shall allow operators to chose one out of two standardised protocol 
suites for transport of SCCP messages. 

1) Broadband SS7 stack comprising MTP3b on top of SAAL-NNI 



£75/ 



(3G TS 23.121 version 3.2.0 Release 1999) 



10 



ETSI TS 123 121 V3.2.0 (2000-01) 



2) lETF/Sigtran CTP protocol suite for MTP3 users with adaptation to SCCP. The protocol suite shall fully 
comply with the IETF standards developed by the Sigtran working group. No UMTS specific adaptations 
shall be standardised below the SCCP protocol. 

The grey colour denotes protocols being developed by the IETF sigtran group. 



RANAP 


SCCP 


MTP-3b 


CTP 
(module SCCP/MTP3 users 


SAAL-NNI 


IP 



Figure 4-2: RANAP protocol stack options 



4.2.2 lu User plane 



• The standard shall support that the user data flows transported over the lu reference point to/from the IP domain' 
shall be multiplexed on top of common layer 2 resources. 

• If the lu data transport bases on ATM PVCs then the lu IP layer provides the lu network layer services, e.g. 
routing, addressing, load sharing and redundancy. In this case an IP network may be configured to transfer lu 
data units between RNSs and 3G-SGSNs. 

• One or several AAL5/ATM Permanent VCs may be used as the common layer 2 resources between the UTRAN 
and the IP domain' of the CN. The reason for usage of several permanent AAL5/ATM VCs may e.g. be for load 
sharing and redundancy. It is also possible to use one switched VC per user flow (PDP context or radio access 
bearer). 

• A tunnelling protocol is used on top of this common layer 2. This tunnelling protocol corresponds to an 
evolution of the user plane part of the GTP protocol used in GPRS put on top of UDP/IP. 

• The user data plane in the UMTS network is made up of two tunnels: 

• a first IP/UDP/GTP tunnel between RNC and 3G SGSN on lu 

• a second IP/UDP/GTP tunnel between GGSN and 3G SGSN on Gn 
This architecture: 

• Provides hierarchical mobility 

• Allows having the RNC directly connected on the IP domain backbone 

• Ensures that all traffic is routed through 3G-SGSN that may perform functions such as charging and Lawful 
Interception. 

• Would allow to have different protocols (or protocol version) on Gn and lu if needed in the future 
The protocol stack is shown in Figure 4-3. 
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Figure 4-3: Protocol Architecture for IP domain user plane 

4.2.2.1 Principles of User Data Retrieve in UMTS and at GSM- UMTS Hand-Over for 

PS Domain 



4.2.2.1.1 



Requirements for Data retrieve at GPRS/UMTS handover 



The same reliability as in inter 2G-SGSN RA update case has to be provided at GPRS to/from UMTS handover. 
Therefore, the data retrieval should be ensured between 2G-SGSN and SRNC as it is ensured between two 2G-SGSNs. 

Between two 2G-SGSNs, data retrieve is carried out via the Gn interface i.e. via GTP-u^/UDP/IP. In order that the 2G- 
SGSN is not modified for data retrieve with the SRNC, the 2G-SGSN should keep the same protocol stack. 



4.2.2.1.2 



Adopted solution for data retrieve at GPRS-UMTS handover 



For Control Plane: Since some parameters transported by GTP-c are CN related only (e.g. CN classmark,...), it is 
necessary to terminate GTP-c signalling exchanged with the 2G-SGSN in the 3G-SGSN, and to use RANAP signalling 
on lu between 3G-SGSN and SRNC. 

For User plane: As Charging of the retrieved data is to be carried out at 3G-SGSN, data exchanged between SRNC and 
2G-SGSN are handled by the 3G-SGSN (two GTP pipes: SRNC - 3G-SGSN and 3G-SGSN - 2G-SGSN ). This 
ensures that: 

• 3G-SGSN can increment charging counters for user data sent from 2G-SGSN to SRNC 

• 3G-SGSN can decrement charging counters for user data sent from SRNC to 2G-SGSN avoiding that such data 
are charged twice (in 3G-SGSN and in 2G-SGSN) 



1 



GTP-U stands for GTP user plane protocol 
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pipes 

Figure 4-4: Data retrieve between GPRS and UIUITS 

4.2.2.1 .3 Requirements for data retrieve in UMTS 

Note: this section deals with the case of SRNS relocation and of UMTS hard hand-over (when this hard hand-over 
involves also the CN i.e. involves a change of Serving RNC). 

Since, 

there is no buffering in the 3G-SGSN 

there is an ARQ mechanism in the Serving RNC (the RLC layer) similar to the LLC layer in the 2G-SGSN, 

the data reliability is ensured by the transfer of non-acknowledged user data from the Source RNC to the Target RNC. 
This transfer ("data retrieve") can be performed with a mechanism similar to the one used between 2G-SGSNs in 
GPRS. 

The Data retrieve between two RNCs belonging to the same UTRAN is required for non real-time data services during 
a SRNS relocation procedure. 

Regarding the SRNS Relocation procedure Control Plane, SRNS relocation procedure uses both RANAP signalling 
over the lu and RNSAP signalling over the lur. 



Regarding the user plane, some requirements can be listed: 

Synchronisation: 

Since the 3G-SGSN does not buffer downstream data, the source RNC may have to buffer all GTP frames that are not 
yet transmitted or acknowledged at RLC layer. It also has to buffer all GTP frames that continue to arrive from the 
GGSN (the GGSN continues to send them to the source RNC as long as its PDP context has not been updated by the 
SGSN. Furthermore, data that are sent by the GGSN may take a certain time to get to the source RNC). 

This means that: 
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The target RNC has to start as Serving RNC just after having received SRNS Relocation Commit message from the 
source RNC even if all downstream data have not been retrieved yet. 

The user data retrieve may last a relatively long time. A timer is armed in the Source SRNC at the beginning of the data 
transfer phase. The contexts related to the UE in the Source SNRC will be released when the timer expires, i.e. when 
downstream data from GGSN is considered as finished. 

Data reliability: 

Depending upon the required reliability, there could be a need for a layer 2 protocol or not. In the GPRS, the user data is 
transfer via GTP/UPD/IP if the user-to-user data is IP -based, and via GTP/TCP/IP if the user-to-user data is X25-based. 
Here, only GTP/UDP/IP is considered. 

Multiplexing of PDP contexts during data retrieve: 

Several SRNS Relocation procedures for different users and/or different bearers may be carried out simultaneously and 
independently. GTP is used to differentiate the data retrieve contexts. 

Associated signalling: 

Considering signalling, there are two kinds of signalling: 

Signalling linked with transmission of CN parameters. This corresponds to signalling exchanged on Gn between 3G- 
SGSNs during the (first) phase of resources for the SRNS relocation. 

Signalling linked with the transmission of the sequence numbers of the acknowledged protocol (RLC) between SRNC 
and UE. This can be done over lur when the source SRNC actually hands-over the role of SRNC (when sending the 
RNSAP "Relocation commit" to the target SRNS). 

4.2.2.1 .4 Adopted solution for data retrieve in UMTS 

Data Retrieve procedure at SRNS relocation shall be carried out through the lu interface: data exchanged between 
source and target SRNC are carried over lu at ATM layer. They are routed at IP layer towards the target SRNC and 
there is one single GTP tunnel between the source SRNC and the target SRNC. 




,^ dser data streai 




RNSAP 
Signalling 



RLC RLC 




v/ 



UE 



data retrieve via 3G-SGSN 
Figure 4-5: User data Retrieve in UIUITS 
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4.2.2.1.5 



User plane protocol stacks for UMTS data retrieve 



The user plane for data retrieve between two RNCs is based on GTP-u/UDP/IP. The GTP connections are terminated in 
the source SNRC and the target SRNC as described in the following figure. 
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4.2.2.1.6 



Figure 4-6: User plane protocol stack for data retrieve in UMTS 



User plane protocol stacks for data retrieve between UTRAN and 2G-SGSN 



The user plane for data retrieve between UTRAN and 2G-SGSN is based on GTP-u/UDP/IP. The protocol stack and the 
GTP connections termination points are described in the following figure. 
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4.2.2.2 



Figure 4-7: User plane protocol stack for data retrieve between GPRS and UMTS 



Packet buffering in SRNC and transmission of not yet acknowledged 
downstream packets at SRNC relocation 



Due to the bursty nature of IP traffic and due to the limited amount of downstream radio resources, some (large) 
buffering capacity is needed in the network to absorb the traffic peaks that arrive as there are not enough radio resources 
to send them to the UE(s). Only this kind of buffering is considered in the rest of this section. 

Large buffering capacity in both CN and SRNC would add to the: 

cost of the network (duplication of memory resources) 

transit delay (packets may have to stay in 2 large queues) 
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complexity of the system (coordination between CN and SRNC for buffer management and associated packet 
scheduling according to QoS) 

As a consequence such (large) buffers should only be put in one place (CN or SRNC). 

RNC-UE procedures (ARQ RLC) ensure data reliability as long as SRNS relocation or GSM <-> UMTS Hand-Over are 
not needed. Large buffering capacities as well as procedures to ensure data reliability at SRNS relocation and GSM <-> 
UMTS Hand-Over (transmission between old and new nodes of downstream packets not yet acknowledged by the UE) 
should be put where ARQ procedures are located. 

Hence the acknowledgement layer LLC that is needed in GSM/GPRS is not needed between CN and UE in UMTS 
because data reliability is provided between UE and SRNC. In case of SRNS relocation or GSM <-> UMTS Hand- 
Over, transmission of not yet acknowledged downstream packets between (old and new) SRNC or between SRNC and 
2G-SGSN provide the necessary reliability. 

Hence large buffers to absorb peaks of downstream traffic as well are not needed in the CN and no flow control 
between CN and UTRAN needs to be defined in order to control the IP domain user plane flow. 

4.2.2.3 Load sharing 

To ensure the necessary load sharing on the Iu_PS interface, 

When the CN requests the establishment of a Radio Access Bearer (associated with a PDP context) or at SRNS 
relocation for all Radio Access Bearers (associated with PDP contexts) of an UE, the CN specifies the IP address of the 
packet processing function allocated to this / each of these PDP context(s) in the CN. 

In the response to the CN request, the RNC specifies the IP address of the packet processing function allocated to this / 
each of these Radio Access Bearer(s) in the RNC. 

When it sends downstream traffic in a RAB, the packet processing function in the CN sends the packet to the RNC IP 
@ received from the SRNC at RAB establishment or at SRNS relocation. 

When it sends upstream traffic in this RAB, the packet processing function in the RNC sends the packet to the CN IP @ 
received from the CN at RAB establishment or at SRNS relocation. 

4.3 UMTS Mobility Management (UMM) 

From a logical point of view, the CN encompasses two domains, a PSTN/ISDN domain and an IP domain. It shall be 
possible to connect the UTRAN either to both these CN domains or to one of the CN domains. 

A single RRC connection (between UTRAN and UE) shall carry all user plane and signalling flows to/from a UE. This 
is regardless of where in the CN they originate/terminate. 

UMTS shall support compatibility with GSM network from the point of view of roaming and handover. For the 
LM/MM functionality point of view this implies among other things the following: 

a) IMSI shall be used as the common user identity in the two CN domains. 

b) Common MAP signalling will be applied to both GSM and UMTS. The GSM MAP mobile service operations 

shall be evolved and re-used as far as possible (including extensions if required). This should not stop new 
MAP signalling operations being developed and applied to both GSM and UMTS. 

c) Radio network parameters and radio resource management should be isolated in the UTRAN. 
The LM/MM techniques used in UMTS should minimise radio resource usage of the UTRA 

4.3.1 Location Management and Mobility Management concept overview 

From a logical point of view, the Core Network (CN) consists of two service domains, a CS service domain (earlier 
named PSTN/ISDN domain) and a PS service domain (earlier named IP domain) or one of these domains. 
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Each service domain has its own service state machine. An UE, that is supporting both CS services and PS services, has 
a CS service state machine and a PS service state machine. The two peers of the service state machine are working 
independently to each other, ahhough associated to the same UE. The UE-CN signalUng aims to keep the peer entities 
synchronised. 

As an introduction. Figure 4-8 and Figure 4-9 below give an overview of the UE registration and connection principles 
within the UMTS when the CN consists of two separate PS and CS service nodes or one combined CS and PS service 
node. 
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Two CN service domains 




T — Two lu signalling connections 
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{ 'CS state \ ; PS state 
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Figure 4-8: Overview of the UE registration and connection principles within UMTS for the separate 

CN architecture case when the CN consists of both a CS service domain with evolved MSC/VLR, 

3G_MSC/VLR, as the main serving node and an PS service domain with evolved SGSN/GGSN, 

3G_SGSN and 3G GGSN, as the main serving nodes, 
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Figure 4-9: Overview of the UE registration and connection principles within UIUITS for the integrated 
CN architecture case when the CN consists of both a CS service domain and an PS service domain 

with an UIVISC as the main serving node. 

The main PS service states are PS-DETACHED, PS-IDLE and PS-CONNECTED. The main CS service states are CS- 
DETACHED, CS-IDLE and CS-CONNECTED. For the respective service domain there are specific related MM 
system information controlhng the MobiHty Management functionaUty of the UE 

The aim of UTRAN is to offer one unified set of radio bearers which may be used for bursty packet traffic and for 
traditional telephony traffic. This leads to the conclusion that only one logical control channel structure will be used for 
all kind of traffic. The radio resource handling is UTRAN internal functionality and the CN does not define the type of 
radio resource allocated. 

The Radio Resource Control (RRC) has two modes, RRC Connected mode and RRC Idle mode. The RRC mode 
describes which identity is used to identify the UE. In RRC Idle mode the UE is identified by a CN associated identity. 
In RRC Connected mode the UE is assigned a Radio Network Temporary Identity to be used as UE identity on common 
transport channels. When the UE is allocated dedicated transport channels, it uses the inherent addressing provided by 
these transport channels. 

In PS-CONNECTED state the UE is in RRC Connected mode. In CS-CONNECTED state the UE is in RRC Connected 
mode. 

For the mobility functionality, four different area concepts are used. Location Areas and Routing Areas are used in the 
Core Network. UTRAN Registration Areas and Cell Areas are used in UTRAN. Location Areas are related to CS 
services. Routing Areas are related to PS services. 

One Location Area is handled by one CN node. For an UE that is registered in a Location Area, this implies that the UE 
is registered in the specific CN node handling this specific Location Area. One Routing Area is handled by one CN 
node. For an UE that is registered in a Routing Area, this implies that the UE is registered in the specific CN node 
handling this specific Routing Area. Location Area is used by the 3G_MSC/VLR for paging the UE. Routing Area is 
used by the 3G_SGSN for paging the UE. UTRAN Registration Areas and Cell Areas are only visible in UTRAN and 
used in RRC -Connected mode. 

For the relations between Location Area (LA) and Routing Area (RA) is described in section 4.3.2. . 
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In RRC Idle mode it is the broadcasted MM system information (e.g. information about the present Location Area and 
present Routing Area) that determines when the UE initiates a location registration procedure towards the CN. An UE 
in state CS-IDLE will in RRC Idle mode, initiate Location Area update towards the CN when crossing LA border. An 
UE in state PS -IDLE will in RRC Idle mode initiate Routing Area update towards the CN when crossing RA border. 

In RRC Connected mode, the UE receives the MM system information on the established RRC connection. (I.e. the 
broadcasted MM system information is not used by the UE in the RRC connected mode.) An UE in state CS-IDLE will, 
in RRC Connected mode, initiate Location Area update towards the CN when receiving information indicating a new 
Location Area. An UE in state PS-IDLE will, in RRC Connected mode, initiate Routing Area update towards the CN 
when receiving information indicating a new Routing Area. An UE in state CS-CONNECTED will, in RRC Connected 
mode, not initiate Location Area update towards the CN. An UE in state PS- CONNECTED will, in RRC Connected 
mode, not initiate Routing Area update towards the CN. 

In CS -DETACHED mode the UE will not initiate any Location Area update and this independent of the RRC mode. In 
PS-DETACHED mode the UE will not initiate any Routing Area update and this independent of the RRC mode. 

In additional to normal location registration when changing registration area, the UE may (network options) perform CS 
periodic registration when in CS-IDLE state and PS periodic registration when in PS-IDLE state. The respective 
periodic registration may be on/off on Location Area respective Routing Area level. 

On the Mobility Management level, IMSI and CS related TMSI are used as UE identities in the CS service domain, and 
IMSI and PS related TMSI are used as UE identities in the PS service domain. The IMSI is the common UE identity for 
the two CN service domains. 

A signalling connection between the UE and the CN refers to a logical connection consisting of an RRC connection 
between UE and UTRAN and an lu signalling connection ("one RANAP instance") between the UTRAN and the CN 
node. The CS service domain related signalling and PS service domain related signalling uses one common RRC 
connection and two lu signalling connections ("two RANAP instances"), i.e. one lu signalling connection for the CS 
service domain and one lu signalling connection for the PS service domain. 

4.3.1 .1 Use of combined procedures for UMTS 

The use of separated PS and CS mobility mechanisms within the UE and within the CN may lead to non-optimal usage 
of the radio resource (for example a UE in PS idle and CS idle state would perform both location updates (for the CS 
mechanism) and Routing area updates (for PS mechanisms)). 

UMTS should optimise the use of radio resources.. The use of combined updates (similar to the current GSM/GPRS Gs 
combined update mechanism) may enable this. To offer flexibility in the provision of mobility management for UMTS, 
it should be possible to use combined mechanisms for location management purposes as well as for attach/detach status 
purposes. 

From the UE perspective it should be possible for the UE to perform combined update mechanisms (operator option). 
UMTS Phase 1 R99 terminals should support the use of both combined and separate mechanisms. The support of this 
feature by all UMTS mobiles will also ease evolution of UMTS MM in the future. 

In the UMTS specifications the RAN will not co-ordinate mobility management procedures that are logically between 
the core network and the MS. This includes: location management, authentication, temporary identity management and 
equipment identity check. 

The issues of security, temporary identifiers, CS and PS periodic registrations and PS DETACHED/CS DETACHED 
need to be studied. 

4.3.2 Description of the Location Management and Mobility Management 
Concept 

4.3.2.1 Area concepts 

For the mobility functionality four different area concepts are used. Location Area and Routing Area in the CN as well 
as UTRAN Registration Area and Cell areas in the UTRAN. 
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4.3.2.1.1 Location areas 

For CS services, the CN uses Location Areas (LA). Location Area is used e.g. at CN initiated paging related to CS 
services. A CS service related temporary identity, CS -TMSI, may be allocated to the UE. This temporary identity is 
then unique within a LA. 

4.3.2.1.2 Routing areas 

For PS services, the CN uses Routing Areas (RA). Routing Area is used e.g. at CN initiated paging related to PS 
services. A PS service related temporary identity, PS-TMSI, may be allocated to the UE. This temporary identity is then 
unique within a RA. 

4.3.2.1 .3 UTRAN internal areas 

UTRAN internal areas are used when the terminal is in RRC-Connected mode (see chapter 3.3). The areas are used at 
e.g. UTRAN initiated paging. UTRAN internal area updating is a radio network procedure and the UTRAN internal 
area structure should not be visible outside UTRAN. In RRC connected mode, the UE position is known on cell level or 
on UTRAN Registration Area (URA) level. RNTI is used as a temporary UE identifier used within UTRAN and 
allocated at RRC connection establishment. 

4.3.2.1 .4 Relationship between the different areas 

The following area relations exist: 

• There may not be any relation between URA and LA respectively between URA and RA. The URA concept is 
defined in TS 25.33 L 

• One RA consists of a number of cells belonging to RNCs that are connected to the same CN node. 

• One LA consists of a number of cells belonging to RNCs that are connected to the same CN node. 

• One RA is handled by only one CN serving node, i.e. one UMSC or one 3G_SGSN. 

• One LA is handled by only one CN serving node, i.e. one UMSC or one 3G_MSC/VLR. 

The GSM defined relations between LA and RA applies i.e. the following relations between LA and RA are possible: 

- RA and LA is equal 

- one RA is a subset of one, and only one, LA, meaning that a RA do not span more than one LA 

The mapping between one LA and RNCs is handled within the MSCA'^LR owning this LA. The mapping between one 
RA and RNCs is handled within the SGSN owning this RA. The mapping between LA and cells respective between RA 
and cells is handled within RNC. 
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Area Concepts 
(Cells are not shown) 
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4.3.2.1.5 
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Figure 4-10: Relationship between different areas. 

Hierarchical tracking concept 



A packet UE (in RRC connected mode) is tracked at the cell level by RNC during an active connection. 

A packet UE (in RRC connected mode) is tracked at the URA level by RNC when no data are actively transfer, and the 
probability of data transfer is quite high. 

A packet UE (in PS-Idle state) is tracked at the Routing Area level by SGSN when no data is actively transfered and the 
probability of data transfer is quite low. The network operator should be able to optimise paging and updating load by 
controling the size of the different areas and the probability of data transfer (controlled by the RRC_connection_release 
timer). For example, one operator may decide that URA are small, and that RRC connection are released after a 
relatively short time of inactivity, so that most attached packet UE are tracked in the Routing Area level (optimum for 
packet UE mainly using client-server type of service). 

Another operator may decide that URA are large, and that RRC connection are released only if RRC connection is lost, 
so that most attached packet UE are tracked at the URA level. 

Different timer values are required for the URA Update Timer and for the RRC Connection Release Timer. It is for 
further study whether the duration of the RRC_Connection_Release timer is set on a per UE basis, or configurable by 
the operator to be the same for all UE. 

4.3.3 Relationship between MM and SM states for an UE 

When a UE is attached to PS service, it may have or not some PDP context established. 

If the UE has no PDP context established (SM-Inactive), no radio access bearer are established for PS service. The UE 
is in RRC connected mode, only if the state is UMTS CS-CONNECTED state or UMTS PS-CONNECTED state (i.e. 
only a PS signaling connection is established). 

If the UE has at least one PDP context established (SM-Active), the UE may be in UMTS PS-CONNECTED state or in 
UMTS PS-IDLE state. 

Note: The PDP context status is not modified by the release of the RRC connection, except if the release of the 
connection is due to an RRC failure which do not permit to maintain the negotiated QoS (e.g. a real time connection). 
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4.3.4 Requirement in case of temporarily loss of coverage of packet UE 

A packet attached UE using non-real time bearer shall not lose its PDP context in case of temporarily loss of coverage. 
AUE specific Mobile Reachable Timer should monitor how long PDP context(s) are kept after a UE has lost coverage. 

4.3.5 MM functionality in different UE service states 

Below are the main UE service states and related MM functionality described. For the determination on when LA or 
RA is changed, see chapter on "Handling of MM system information". 

CS service states and related MM functionality: 

CS-DETACHED: The UE is not reachable by the network for CS services. The UE does not initiate LA updates at 
LA changes and no periodic CS service updates. 

CS-IDLE: The UE is reachable by paging for CS services. The UE initiates LA updates at LA changes. The UE may 
initiate periodic CS service updates and this depending on the CS periodic update state of the present LA. 

CS-CONNECTED: The UE has a signalling connection for CS services established between the UE and the CN. 
The UE does not initiate LA update (even not when the present LA changes) and no periodic CS service updates. 

PS service states and related MM functionality: 

PS-DETACHED: The UE is not reachable by the network for PS services. The UE does not initiate RA updates at 
RA changes and no periodic PS service updates. 

PS-IDLE: The UE is reachable by paging for PS services. The UE initiates RA updates at RA changes. The UE may 
initiate periodic PS service updates and this depending on the PS periodic update state of the present RA. 

PS-CONNECTED: The UE has a signalling connection for PS services established between the UE and the CN. The 
UE initiates RA update when RAI in MM system information changes. No periodic PS service updates. 

There may also be a NULL state. In the UE, this state corresponds to power off or maybe a "no SIM" condition. In the 
CN, the NULL state correspond to CS-DETACHED and PS-DETACHED 

For each state transition there can be several events that triggers the transition. Some of them are described below. Note 
that some of these may coincide, e.g. moving from CS-IDLE to CS-DETACHED and moving from PS-IDLE to PS- 
DETACHED. 

Moving from CS-IDLE to CS-CONNECTED: 

The state transition from CS-IDLE to CS-CONNECTED is performed when a signalling connection is established 
between UE and CN for CS services. In GSM this state transition is triggered by the message 
CM_SERVICE_REQUEST or PAGE_RESPONSE. 

Moving from CS-CONNECTED to CS-IDLE: 

The state transition from CS-CONNECTED to CS-IDLE is performed when the signalling connection for CS services is 
released, e.g. at call release and no other CS service is ongoing. A radio link failure may also trigger this state transition. 

Moving from CS-IDLE to CS-DETACHED: 

The transition from CS-IDLE to CS-DETACHED may be triggered by some action from the user of the UE but an 
expiring timer in the network could also trigger it. The UE is marked as CS_DET ACHED in the CN and then as a 
consequence no CS service establishment is possible. 

Moving from PS-IDLE to PS-CONNECTED: 

The state transition from PS-IDLE to PS-CONNECTED is performed when a signalling connection is established 
between UE and CN for PS services. 

Moving from PS-CONNECTED to PS-IDLE: 
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The state transition from PS-CONNECTED to PS-IDLE is performed when the signalling connection for PS services is 
released, e.g. at release of a PS service, no other PS service is ongoing and at release of the RRC connection in case of 
very low level of activity. A radio link failure may also trigger this state transition. 

Moving from PS-IDLE to PS-DETACHED: 

The transition from PS-IDLE to PS-DETACHED may be triggered by some action from the user of the UE but an 
expiring timer in the network could also trigger it. The UE is marked as PS_DET ACHED in the CN and then as a 
consequence no PS service establishment is possible. 

4.3.6 The RRC state machine 

The RRC state machine is a description model of how the UE and the UTRAN co-operate regarding RRC functionality. 
The RRC state describes the state of the UE in the UTRAN. Here follows a brief description of the RRC state machine, 
for more information see [UMTS YY.Ol] and [UMTS YY.03]. 

Note: RRC idle mode and RRC connected mode refer to the UE idle mode and UE connected mode respectively in 
[UMTS YY.Ol] and [UMTS YY.03]. 

The RRC state machine exists as peer entities, one in the UE and one in UTRAN. Apart from transient situations and 
error cases they are synchronised. The figure below illustrates the main modes/states of the RRC state machine. 
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Figure 4-11 : RRC modes, main RRC states and main mode/state transitions 

RRC-Idle_mode 

In the Idle mode there is no connection established between UE and UTRAN. There is no signalling between UTRAN 
and the UE except for system information that is sent from UTRAN down link on a Broadcast channel to the UE. The 
UE can also receive paging messages with a CN identity on the PCH. There is no information on the UE stored in 
UTRAN in this state. 

RRC-Connected_mode 

In the Connected mode the main states are Cell Connected state and URA connected state. In this mode there is one 

RNC that is acting as Serving RNC (SRNC), and an RRC connection is established between the UE and this SRNC. 

• When the UE position is known on cell level, the UE is in the cell connected state. When in cell connected state, 
the RRC connection mobility is handled by handover procedures. 

• When the UE position is known on URA level, the UE is in the URA connected state. The URA contains a set of 
cells. URA updating procedures provides the mobility functionality in this state. In URA connected state no 
dedicated radio resources are used. 
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4.3.7 Relationship between CS and PS service states and RRC state for 
anUE 

During non-transient conditions the following relations are valid between service states and RRC modes for an UE: 

When in either CS-CONNECTED state or PS-CONNECTED state, or in both CS-CONNECTED state and PS- 
CONNECTED state, then the UE is in RRC connected mode. 

When in neither CS-CONNECTED state nor PS-CONNECTED state, then the UE is in RRC idle mode. 

Figure 4-12 and Figure 4-13 illustrate two examples on the relations between the RRC states and CS/PS service states. 
These figures illustrate the separated CN case. 
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Figure 4-12: UE in CS-CONNECTED state and PS-IDLE state. 
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Figure 4-13 

4.3.8 Service registration and location update 

Service registration (attach) in the respective CN service domain is done initially (after UE being detached due to e.g. 
power off). When a registration area is changed a location update is performed. In addition, periodic registration can be 
performed. Here follows descriptions of when the respective CN registration area is changed. Note it is not here defined 
which different registration procedures that are needed. 



4.3.8.1 



Location area update 



Location area update is initiated by the UE to inform the CS service domain of the core network that the UE has entered 
a new location area. In case the new location area is in an area served by another CN node, the location area update also 
triggers the registration of the subscriber in the new CN node and a location update for CS services towards the HLR. 

Location area update is only initiated by the UE when the UE is in state CS-IDLE, and this independently of the PS 
state. If the UE is CS-IDLE but RRC connected, which means that the UE is in PS-CONNECTED state, location area 
update is initiated by the UE when it receives information indicating a new location area (see also the chapter "Handling 
of MM system information"). 



4.3.8.2 



Routing area update 



Routing area update is initiated by the UE to inform the PS service domain of the core network that the UE has entered 
a new routing area. In case the new routing area is in an area served by another CN node, the routing area update also 
triggers the registration of the subscriber in the new CN node and a location update for PS services towards the HLR. 

Routing area update is initiated by the UE when the UE is in state PS-IDLE, and this independently of the CS state. If 
the UE is PS-IDLE but RRC connected, which means that the UE is in CS-CONNECTED state, routing area update is 
initiated by the UE when it receives information indicating a new routing area (see also the chapter "Handling of MM 
system information"). 

When the UE is in PS-CONNECTED state the UE initiates RA update when RAI in MM system information changes. 



4.3.8.3 



Combined updates 



The GSM radio interface combined procedures and their support via the Gs interface is the starting point for the support 
of combined updates.. 
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4.3.9 Paging initiated by CN 

Here follows a possible solution with a page co-ordination within the UTRAN. Other alternatives are possible. 

A CN node requests paging only for UE in CS-IDLE state or PS IDLE state. In the separate CN architecture, paging 
from a CN node is done independent of the service state of the UE in the other CN service domain. 

In this alternative with page co-ordination in UTRAN, the UE does not need to listen to the PCH (Page Channel) in 
RRC connected mode. (At least not when UE is allocated a dedicated channel.) 

At each page request received from a CN node, the RNC controls whether the UE has an established RRC 
connection or not. For this, the context that is build up in the SRNC for UE in RRC connected mode must 
contain the IMSI, i.e. the UE identity common for the two CN domains. 

If no context is found for the UE, "normal PCH paging" is performed. This implies transfer on the Paging channel of 
a page message indicating the UE paging identity received from the CN and a CN service domain type 
indication. 

If a context is found, a "CN paging message" is transferred using the existing RRC connection. This message 
indicates then the UE paging identity received from the CN and a CN service domain type indication. 

In case of a single CN element, paging may be (but not mandatory) co-ordinated at the CN. 

Note: The RNC might use another identity e.g. TMSI, P-TMSI, or other radio related identity, to page the mobile. 

4.3.10 Signalling connection establishment 

A signalling connection between the UE and a CN node refers here to a logical connection consisting of an RRC 
connection between UE and UTRAN and an lu signalling connection between UTRAN and the CN node. The 
signalling connection is used for transfer of higher layer (MM, CM) information between the UE and the CN node. 

At a CM service request to one of the CN service domains, UE will only request establishment of a new signalling 
connection when no such connection exists towards the applicable CN service domain. 

If no RRC connection exists, this is established in conjugation with (before) the transfer of the signalling establishment 
request. At the RRC connection establishment, an UE context is built up in the SRNC. 

If an RRC connection is already established, the UE will send the signalling establishment request using that RRC 
connection. 

At reception of the signalling establishment request, the SRNC will establish an lu connection towards the CN node 
indicated by the CN service domain type received from UE. 

4.3.1 1 Relations between SRNS relocation and Location registration 

This chapter is included in order to clarify the need for separate handling of MM registration area (LA and RA) 
information in RRC idle mode respective in RRC connected mode. The following example illustrates relations between 
SRNC relocation, registration area (LA/RA) change and location/routing area updates. As shown in the example, this is 
equally applicable for a UMSC as well as the 3G-MSC/VLR and 3G-SGSN. 

Note that the example is based on the assumptions that one RNC can set up lu connections to only one 3G_MSC/VLR 
(or UMSC) and only one 3G_SGSN (or UMSC), and that the CN node is configured to only send page to the RNC(s) 
that is controlling cells within the relevant LA/RA 

Preconditions: 

LAI (Location Area 1) is handled by 3G_MSC/VLR1 (or UMSCl) and LA2 is handled by 3G_MSC/VLR2 (or 
UMSC2) 

RAl (Routing Area 1) is handled by 3G_SGSN1 (or UMSCl) and RA2 is handled by 3G_SGSN2 (or UMSC2) 

UE is registered in LAI in 3G_MSC/VLR1 and in RAl in 3G_SGSN1 
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The UE is in PS-CONNECTED state and a signalling connection exists between UE and 3G_SGSN1 

The UE is in CS-IDLE state and no signalling connection exists between UE and 3G_MSC/VLR1 

RNCl is acting as SRNC and RNC2 is acting as DRNC 

UE is in RRC cell connected state and with dedicated channels established to cells within both RNCl and RNC2. 
UE does not listening to the PCH. 

The registration area information sent to the UE indicates LAI and RAl 

The UE can always (at least in normal working states) identify the present available registration area (LA respective 
RA) associated with the respective CN service domain. The determination of the present area differs depending on the 
state of the UE. For UE in RRC idle mode (UE with no ongoing communication with the network) it is the cell selection 
mechanism in the UE that is used. For UE in RRC connected mode it is the UTRAN that determines the area (although 
a change can implicit be initiated by the UE). 

It is the network that supplies the MM system information to the UE. For UE in RRC idle mode the MM system 
information is provided by the system information broadcasting function. For UE in RRC connected mode, the MM 
system information is supplied by the SRNC to the UE at each change of this information. This leads to that in RRC 
connected mode, the MM registration area (e.g. LA and RA) information sent on broadcast channel is not used. 



Or UMSCl Or UMSC2 

"mscT^ (^gsnT^/ \.(!^sc2~^ (^sgsnT).; 



% 'tt 



Figure 4-14: Illustration of the preconditions in the described example. In this figure MSC stands for 

3G_MSC/VLR and SGSN for 3G_SGSN. 

The UE moves now further towards right, leaving the coverage area of cells controlled by RNCl, and resulting in that 
the UE has dedicated channel(s) established to cell(s) within only RNC2. This may result in the following sequence of 
events: 

The SRNC (RNCl) may decide to perform an SRNC relocation resulting in that the RNC2 becomes SRNC. The 
change of SRNC will in this example also imply a change of SGSN (or UMSC) with an update of the UE 
location registration for the PS service domain. 

After this SRNC relocation or combined with this procedure, the MM registration area information sent to the UE is 
changed and indicates now LA2 and RA2. ( Note that the MM registration area information need not be sent for 
every SRNS relocation, nor does it preclude MM registration area information being sent in other occasions.) 

The changed MM registration area information will result in that the UE initiates a location update, which results in 
a registration change from LAI in 3G_MSC/VLR1 to LA2 in 3G_MSC/VLR2. 

The area information can not be changed to indicate LA2 unless SRNC relocation has been performed. This since the 
location update signalling will be sent from the UE, by using the established RRC connection to SRNC, and then to the 
3G_MSC/VLR to which the SRNC belongs. 
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4.3.12 Requirements on Identifiers for UMTS and GSM 

la) The format of the UMTS Location Area Identifier and UMTS TMSI shall not prevent a dual mode GSM-UMTS 
mobile which was last location updated over the GSM radio interface (i.e. has a GSM LAI and GSM TMSI), from 
performing a location update (or other signalling) over the UMTS radio interface to a UMTS MSC. 

lb) The format of the UMTS Location Area Identifier and UMTS TMSI shall not prevent a dual mode GSM-UMTS 
mobile which was last location updated over the UMTS radio interface (i.e. has a UMTS LAI and UMTS TMSI), from 
performing a location update (or other signalling) over the GSM radio interface to a GSM MSC. 

Ic) The format of the UMTS Routing Area Identifier and UMTS P-TMSI shall not prevent a dual mode GSM-UMTS 
mobile which was last routing area updated over the GSM radio interface (i.e. has a GSM RAI and GSM P-TMSI), 
from performing a routing area update (or other signalling) over the UMTS radio interface to a UMTS SGSN. 

Id) The format of the UMTS Routing Area Identifier and UMTS P-TMSI shall not prevent a dual mode GSM-UMTS 
mobile which was last routing area updated over the UMTS radio interface (i.e. has a UMTS RAI and UMTS P-TMSI), 
from performing a routing area update (or other signalling) over the GSM radio interface to a GSM SGSN. 

2) The standard shall support means by which an operator can configure GSM and UMTS cells to be members of the 
same registration area (i.e. the mobile can receive paging from whichever cell it is camped on and does not need to 
location update (or routing update) just because the mobile has changed from a UMTS to a GSM cell). 

3a) The standard shall support means by which an operator can allocate GSM and UMTS LAIs which enable GSM 
MSCs to be able to contact UMTS MSCs and vice versa. 

3b) The standard shall support means by which an operator can allocate GSM and UMTS RAIs which enable GSM 
SGSNs to be able to contact UMTS SGSNs and vice versa. 

4) The standard shall support means by which an operator can ensure that the IMSI does not need to be sent over the 
radio interface when the mobile station moves from a GSM cell to a UMTS cell (and vice-versa). 

5) The standard shall support means by which an operator can ensure that the IMSI does not need to be sent over the 
radio interface when a USIM is moved from a UMTS mobile station to a GSM mobile station (and vice-versa). 

6) The standard need not support means by which an operator can ensure that the IMSI is not sent over the radio 
interface when a GSM SIM is moved from a GSM mobile station to a UMTS mobile station (and vice-versa). 



4.3.13 Use of TMSI signature 



The TMSI signature concept shall be used during the IMSI attach procedure, IMSI detach procedure and during the 
location update procedure. However, it may also be used in almost all cases when authentication is performed e.g. call 
setup. Note that if the TMSI is sent in the clear, then a new one should be issued. As the use of a P-TMSI signature is 
already defined within GPRS, only the modifications necessary for CS service domain shall be shown below. 

4.3.13.1 IMSI attach 

The figure bellow shows the signalling procedure for a first time (IMSI based) attach (i.e. when no TMSI is available in 
the UE). The following list explains the relevant steps involved in the procedure. 
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Figure 4-15: Attach Procedure using TlUISi signature 

1). An RRC connection is established. 

2). Upon the very first attach towards the network, the MS shall send a Location Area Update Request message towards 
the MSC/UMSC, indicating an IMSI attach, and identifying itself with IMSI. 

2-6) The LA updating procedure shall be carried out as per normal within the network. 

7). The MSC/UMSC shall optionally generate and send a TMSI signature within the Location Area Update Accept 
message to the MS, which will be stored by the MS. 

8) The MS acknowledges the new TMSI. 

9). The RRC connection may be released. 

4.3.1 3.2 Location Area update 

The figure bellow shows the signalling for a location update procedure involving change of 3G-MSC / UMSC. Note 
that when the authentication procedure using TMSI signature is successful, security functions using Ki are no longer 
required. The following list explains the relevant steps involved in the procedure. 



£75/ 



(3G TS 23.121 version 3.2.0 Release 1999) 



29 



ETSI TS 123 121 V3.2.0 (2000-01) 



New UMSC 
3GMSC 



HLR 



Old UMSC 
3G-MSC 



1 . RRC connection 
establishment 

4- W 

2. LA Update Req.(old 
LAI, old TMSI, old TMSI 
signature) 



3. Send Identification Req.(TMSI, 
TMSI signature) 



4. Send Identification Ack.(IMSI, triplets) 



*5. Security Functions 



12. Location Update Accept 
(new LAI, new TMSI, new 
TMSI signature) 



I \ 

13. TMSI reallocation 
complete (new TMSI) 



14. RRC 

connection 

release 



14. Release 



6. Update Location 



9. Insert Subscriber Data 



7. Cancel Location 

►! 

I. Cancel Location Ack 



10. Insert SubscriberDataAck 

H 

11. Upd. Location Ack 



Figure 4-16: Location Update using TIVISI signature 

1) An RRC connection is established. 

2) The UE shall send a Location Area Update Request (old LAI, old TMSI, old TMSI signature) towards the new 
UMSC/MSC. 

3-5) The new UMSC/MSC shall send a Send Identification Request (TMSI, TMSI signature) to the old UMSC/MSC. 
The old UMSC validates the old TMSI signature and responds with an appropriate error cause if it does not match the 
value stored. This should initiate the security function in the new UMSC. Otherwise, the old UMSC responds with a 
Send Identification Acknowledge (IMSI, Authentication triplets). 

6-11) The LA updating procedure shall be carried out as per normal within the network. 

12) The new UMSC/MSC shall optionally generate and send a TMSI signature within the Location Area Update Accept 
message to the UE. 

13) The UE acknowledges the new TMSI. 

14) The RRC connection may be released. 

4.3.13.3 MM System Information 

The system information that is needed for the Mobility Management functionality contains parameters such as: 

MCC, MNC, LAC, RAC, Periodic Location Area Update timer, and Periodic Routing Area Update timer. 

In each UMTS cell (UTRAN cell) the network broadcasts MM system information on the broadcast channel. In RRC 
idle mode, when the UE camps on one cell, it receives all MM system information valid for this cell on the broadcast 
channel of the cell. The received MM system information is then the "current MM system information". 

In RRC connected mode, it is the responsibility of the SRNS to control the current MM system information valid for the 
UE. At any changes, the established RRC connection is used for transferring the new MM system information to the 
UE. E.g. at SRNS relocation, the new SRNS shall have logic for sending applicable MM system information to the UE. 
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This information is determined by e.g. the Location Areas and the Routing Areas handled by the respective CN node to 
which the SRNS can set up lu signalHng connections. At reception of new MM system information from the SRNC on 
the established RRC connection, the UE uses this new information as the "current MM system information". (Note that 
the MM system information need not necessarily be sent for every SRNSs relocation, nor does it prelude MM system 
information being sent on other occasions.) 

At the RRC connection establishment, the UE uses the broadcasted MM system information of the cell where the 
establishment is made as the "current MM system information". 

When the UE leaves the RRC connected mode and enters RRC idle mode, the UE uses the broadcasted MM system 
information of the chosen cell, which is determined by the UE idle mode cell selection/re-selection process that is then 
performed, as the "current MM system information". 

The "current MM system information" is used by the MM functionality in the UE respecting the rules for the UE 
service state of the respective MM state machine, see ' 7.3.3MM functionality in different UE service states ' and ' 
7.3.6 Service registration and location update '. 

4.3.1 3.4 IMSI detach procedure 

When the UE performs the detach procedure, TMSI is included in the detach message. If the network has allocated the 
TMSI signature for the UE, e.g., in the previous location update or attach procedure, TMSI signature is included in the 
detach message for the verification purpose. 

4.3.14 Signalling procedures 
4.3.14.1 Idle mode procedures 

The signalling procedures shown in the following sections do not represent the complete set of possibilities, nor do they 
mandate this kind of operation. The standard will specify a set of elementary procedures for each interface, which may 
be combined in different ways in an implementation. Therefore these sequences are merely examples of a typical 
implementation. By default the combined procedures as defined in GSM 03.60 are also applicable when using Gs. 

Furthermore the list of parameters may not be complete, but should only be seen as examples of possible information 
carried by the messages. 

4.3.14.1 .1 Location Area update 

This example shows location registration when changing Location Area including change of 3G-MSCA'^LR and when 
the UE is in MM idle state towards the 3G_MSC/VLR. 

The illustrated transfer of MM signalling to/from the UE uses an established RRC connection. This RRC connection 
can have been established beforehand due to ongoing interwork between UE and 3G-SGSN or be established only for 
this location registration procedure towards the 3G_MSC/VLR. 

For each indicated MM message sent in this case to/from UE, the CN discriminator indicates 3G_MSC/VLR. 
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Figure 4-17: Interface information transfer for location update when changing VLR area 

• The RRC connection is established, if not already done. The UE sends the initial message Location Area Update 
Request (old TMSl, old LAI, etc.) to the new 3G_MSC/VLR. The old TMSl and the old LAI are assigned data 
in UMTS. The SRNS transfers the message to the 3G_MSC/VLR. The sending of this message to 
SG.MSCA'LR will also imply establishment of a signalling connection between SRNS and 3G_MSC/VLR for 
the concerned UE. The 3G_MSC/VLR determines the new Location Area for the UE. Whether the 
3G_MSC/VLR derives the new LAI from information supplied by the UE or by the SRNS is ffs. 

• The new 3G_MSC/VLR sends an Send Identification Request (old TMSl) to the old 3G_MSCA^LR to get the 
IMSI for the UE. (The old LAI received from UE is used to derive the old 3G_MSCA'LR identity/address.) The 
old 3G_MSCA''LR responds with Send Identification Ack. (IMSI and Authentication triplets). 

• Security functions may be executed. 

• The new 3G_MSC/VLR inform the HLR of the change of 3G_MSC/VLR by sending Update Location (IMSI, 
MSC address, VLR number) to the HLR. 

• The HLR cancels the context in the old 3G_MSCA^LR by sending Cancel Location (IMSI). The old 
3G_MSC/VLR removes the context and acknowledges with Cancel Location Ack . 

• The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_MSC/VLR. The new 
3G_MSCA'LR acknowledges with Insert Subscriber Data Ack. 

• The HLR acknowledges the Update Location by sending Update Location Ack. to the new 3G_MSC/VLR. 

• The new 3G_MSC/VLR validates the UE presence in the new LA. If due to regional, national or international 
restrictions the UE is not allowed to attach in the LA or subscription checking fails, then the new 3G_MSC/VLR 
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rejects the location area update with an appropriate cause. If all checks are successful, then the new 
SG.MSCA'LR responds to the UE with Location Area Update Accept (new TMSI, new LAI). 

The UE acknowledges the new TMSI with a TMSI reallocation Complete. (TMSI can optionally be reallocated 
with the TMSI reallocation procedure). 

When the location registration procedure is finished, the 3G_MSC/VLR may release the signalling connection 
towards the SRNS for the concerned UE. The SRNS will then release the RRC connection if there is no 
signalling connection between 3G_SGSN and SRNS for the UE. 



4.3.14.1.2 



Routing Area update 



This example shows location registration when changing Routing Area including change of 3G_SGSN when the UE is 
in MM idle state towards the 3G_SGSN. 

The illustrated transfer of MM signalling to/from the UE uses an established RRC connection. This RRC connection 
can have been established beforehand due to ongoing interwork between UE and 3G_MSCA'^LR or be established only 
for this location registration procedure towards the 3G_SGSN. 

For each indicated MM message sent in this case to/from UE, the CN discriminator indicates 3G_SGSN. 
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Figure 4-18: Interface information transfer for Routing Area update when changing SGSN area 

(successful case) 

• The RRC connection is established, if not already done. The UE sends the initial message Routing Area Update 
Request (old P-TMSI, old RAI, etc.) to the new 3G_SGSN. The old P-TMSI and the old RAI are assigned data 
in UMTS. The SRNS transfers the message to the 3G_SGSN. The sending of this message to 3G_SGSN will 
also imply establishment of a signalling connection between SRNS and 3G_SGSN for the concerned UE. The 
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3G_SGSN determines the new Routing Area for the UE. Whether the 3G_SGSN derives the new RAI from 
information suppHed by the UE or by the SRNS is ffs. 

• The new 3G_SGSN send an SGSN Context Request (old P-TMSI, old RAI) to the old 3G_SGSN to get the IMSI 
for the UE. (The old RAI received from UE is used to derive the old 3G_SGSN identity/address.) The old 
3G_SGSN responds with SGSN Context Response (e.g. IMSI, PDF context information and Authentication 
triplets). 

• Security functions may be executed. 

• The new 3G_SGSN informs the HLR of the change of 3G_SGSN by sending Update GPRS Location (IMSI, 
SGSN number, SGSN address) to the HLR. 

• The HLR cancels the context in the old 3G_SGSN by sending Cancel Location (IMSI). The old 3G_SGSN 
removes the context and acknowledges with Cancel Location Ack. 

• The HLR sends Insert Subscriber Data (IMSI, subscription data) to the new 3G_SGSN. The new 3G_SGSN 
acknowledges with Insert Subscriber Data Ack. 

• The HLR acknowledges the Update GPRS Location by sending Update GPRS Location Ack. to the new 
3G_SGSN. 

• The new 3G_SGSN validate the UEs presence in the new RA. If due to regional, national or international 
restrictions the UE is not allowed to attach in the RA or subscription checking fails, then the new 3G_SGSN 
rejects the Routing Area Update Request with an appropriate cause. If all checks are successful, then the new 
3G_SGSN responds to the UE with Routing Area Update Accept (new P-TMSI, new RAI, etc.). 

• The UE acknowledges the new P-TMSI with Routing Area Update Complete. 

• When the location registration procedure is finished, the 3G_SGSN may release the signalling connection 
towards the SRNS for the concerned UE. The SRNS will then release the RRC connection if there is no 
signalling connection between 3G_MSCA^LR and SRNS for the UE. 

4.3.14.1 .3 Periodic Registration towards both CN nodes without use of Gs 

This example shows Periodic Registration to both the 3G_MSC/VLR and the 3G-SGSN (i.e. no change of registration 
areas) when the UE is in MM idle state and registered in both the 3G_SGSN and the 3G_MSC/VLR. 

The illustrated transfer of MM signalling to/from the UE uses an established RRC connection. This RRC connection 
will be established, is in this case, only for the two registration procedures towards the 3G_SGSN and 3G_MSC/VLR. 

For each indicated MM message sent to/from UE, the CN discriminator indicates either 3G_ SGSN or 3G_MSC/VLR. 
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Figure 4-19: Interface information transfer for periodic registration to 3G_SGSN and 3G_MSC/VLR 

(successful case) 

• The RRC connection is established. The UE sends the initial messages Routing Area Update Request (old P- 
TMSI, old RAI, etc.) to the 3G_SGSN and Location Area Update Request (old TMSI, old LAI, etc.) to the 
3G_MSC/VLR. In both cases, the UE will indicate the cause periodic registration. The sending of the respective 
message to SGSN respective to MSC/VLR will also imply establishment of a signalling connection between 
SRNS and SGSN and a signalling connection between SRNS and MSC/VLR for the concerned UE. 

• Security functions may be executed. 

• The 3G_SGSN respective the 3G_MSC/VLR validates the UEs presence. If all checks are successful, then the 
3G_SGSN responds to the UE with Routing Area Update Accept and 3G_MSC/VLR responds to the UE with 
Location Area Update Accept. 

• When the periodic registration procedure is finished, the 3G_SGSN respective the 3G_MSC/VLR may release 
the signalling connection towards the SRNS for the concerned UE. If both CN nodes release the signalling 
connection towards the SRNS for the concerned UE, then the SRNS will release the RRC connection towards 
the UE. 
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Figure 4-20: Periodic update procedure when the lUIS is attached for both CS and PS services 

An RRC connection is established for the periodic registration. Note that this procedure is invoked only when the UE is 
in MM-idle state. The UE sends a Routing Area Update to the UMSC. The UMSC authenticates the P-TMSI signature. 
If the update is successful it sends a Routing Area Accept message. The RRC connection is then released. 



4.3.14.1.5 



UE initiated Combined Detach Procedure when using Gs/UMSC 



The UE-Initiated Detach procedure when initiated by the UE is illustrated in Figure 4-21. Each step is explained in the 
following list. 
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Figure 4-21 : UE-Initiated Combined Detach Procedure (The procedure for combined detach when 

using Gs is as defined in GSM 03.60) 

• 1) The UE detaches by sending Detach Request (Detach Type, Switch Off) to the UMSC. Detach Type 
indicates which type of detach that is to be performed, i.e., PS Detach only, CS Detach only or combined Detach. 
Switch Off indicates whether the detach is due to a switch off situation or not. 

• If PS detach, any active PDP contexts in the GGSNs regarding this particular UE may be deactivated. This is 
FFS 

• If Switch Off indicates that the detach is not due to a switch off situation, the UMSC sends a Detach Accept to 
the UE. 



4.3.14.2 



SRNS Relocation 



4.3.14.2.1 



SRNS relocation principles 



To carry out SRNS relocation, the source SRNC must launch the SRNS relocation procedure, since it is not the target 
SRNC but the source SRNC that knows the current services of an user. This is done only when this procedure has the 
least adverse effect on user traffic. 
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The SRNC relocation procedures shall ensure that there is only one Serving RNC for an user even if this user has 
services through more than one (IP or ISDN) domain. 

The SRNS relocation procedure is split in 2 phases. In the first one resources are reserved on the new lu interfaces and 
(if needed) inside the CN. Only when this first phase has been successfully carried out for all domains on which the user 
has currently some services, the source SRNC can launch the second phase i.e. hand-over the role of SRNC to the target 
SRNC. 

The signalling procedures shown in the following sections do not represent the complete set of possibilities, nor do they 
mandate this kind of operation. The standard will specify a set of elementary procedures for each interface, which may 
be combined in different ways in an implementation. Therefore these sequences are merely examples of a typical 
implementation. In these examples MSC stands for 3G_MSC/VLR and SGSN stands for 3G_SGSN. 

Furthermore the list of parameters may not be complete, but should only be seen as examples of possible information 
carried by the messages. 

4.3.14.2.2 SRNS relocation (UE connected to a single CN node, 3G_MSC/VLR) followed by 

Location Registration in new Routing Area 

This example shows SRNS relocation when source RNC and target RNC are connected to different 3G_MSC/VLR. 
This is then followed by a Routing Area update procedure towards a new SGSN. Figure 4-22 and Figure 4-23 illustrate 
the situation before respective after the SRNS relocation and location registration. Figure 4-24 illustrates the signalling 
sequence where each step is explained in the following list. 




Figure 4-22: Before the SRNS relocation and location registration 

Before the SRNS relocation and location registration the UE is registered in SGSNl and in MSCl. The UE is in state 
MM idle towards the SGSNl and in state MM connected towards the MSCl. The RNCl is acting as SRNC and the 
RNC2 is acting as DRNC. 
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Figure 4-23: After the SRNS relocation and location registration 

After the SRNS relocation and location registration the UE is still registered in MSCl while the registration in the IP 
domain has changed from SGSNl to SGSN2. The UE is in state MM idle towards the SGSN2 and in state MM 
connected towards the MSCl. The RNC2 is acting as SRNC. 
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Figure 4-24: Interface information transfer for SRNS relocation when UE connected to 3G_MSC/VLR 
followed by location registration in new Routing Area. 

• UTRAN makes the decision to perform the Serving RNC relocation procedure. This includes decision on into 
which RNC (Target RNC) the Serving RNC functionaUty is to be relocated. The source SRNC sends SRNC 
Relocation required messages to the MSC. This message includes parameters such as target RNC identifier and 
an information field that shall be passed transparently to the target RNC. 

• Upon reception of SRNC Relocation required message the Anchor MSC (MSCl) prepares itself for the switch 
and determines from the received information that the SRNC relocation will (in this case) involve another MSC. 
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The Anchor MSC will then send a Prepare SRNC Relocation Request to the applicable non-anchor MSC 
(MSC2) including the information received from the Source RNC. 

• The non-anchor MSC will send a SRNC Relocation Request message to the target RNC. This message includes 
information for building up the SRNC context, transparently sent from Source RNC (UE id., no of connected CN 
nodes, UE capability information), and directives for setting up lu user plane transport bearers. 

When lu user plane transport bearers have been established, and target RNC has completed its preparation phase, 
SRNC Relocation Proceeding 1 message is sent to the non-anchor MSC. 

• The Prepare SRNC Relocation Response that is sent from non-anchor MSC to Anchor MSC will contain the 
SRNC Relocation Proceeding 1 received from target RNC. 

• When the SRNC Relocation Proceeding 1 has been received in the Anchor MSC, the user plane transport bearers 
has been allocated the whole path between target RNC and Anchor MSC and the Anchor MSC is ready for the 
SRNC move, then the Anchor MSC indicates the completion of preparation phase at the CN side for the SRNC 
relocation by sending the SRNC relocation proceeding 2 message to the Source RNC. 

• When the source RNC has received the SRNC Relocation Proceeding 2 message, the source RNC sends a SRNC 
Relocation Commit message to the target RNC. The target RNC executes switch for all bearers at the earliest 
suitable time instance. 

• Immediately after a successful switch at RNC, target RNC (=SRNC) sends SRNC Relocation Complete message 
to the non-anchor MSC. This message is included by the non-anchor MSC in the Complete SRNC relocation 
message that is sent to the anchor MSC. Upon reception of this message, the Anchor-MSC switches from the old 
lu transport bearers to the new ones. 

• After a successful switch at the Anchor MSC, a release indication is sent towards the Source RNC. This will 
imply release of all UTRAN resources that were related to this UE. 

• When the target RNC is acting as SRNC, it will send New MM System Information to the UE indicating e.g. 
relevant Routing Area and Location Area. Additional RRC information may then also be sent to the UE, e.g. 
new RNTI identity. 

• When receiving new MM system information indicating a new Routing Area, the UE will in this case initiate a 
Routing Area update procedure towards the SGSN. 

• Before point (a), in Figure 4-24, the connection is established between UE and Anchor MSC via Source RNC. 

• After point (b), in Figure 4-24, the connection is established between UE and Anchor MSC via Target RNC and 
Non-anchor MSC. 

4.3.14.2.3 SRNS relocation (UE connected to a single CN node, 3G_SGSN) followed by 

Location Registration in new Location Area 

This example shows SRNS relocation when source RNC and target RNC are connected to different 3G_SGSN. Figure 
4-25 and Figure 4-26 illustrate the situation before respective after the SRNS relocation and location registration. Figure 
4-27 illustrates the signalling sequence where each step is explained in the following list. 
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Figure 4-25 Before the SRNS relocation and location registration 

Before the SRNS relocation and location registration the UE is registered in SGSNl and in MSCl. The UE is in state 
MM connected towai'ds the SGSNl and in state MM idle towards the MSCl. The RNCl is acting as SRNC and the 
RNC2 is acting as DRNC. 





Figure 4-26 After the SRNS relocation and location registration 

After the SRNS relocation and location registration the UE is registered in MSC2 and in SGSN2. The UE is in state 
MM connected towai-ds the SGSN2 and in state MM idle towards the MSC2. The RNC2 is acting as SRNC. 

At SRNS relocation: 

The source and target SGSN exchange CN level information (CN classmark, list of established PDF contexts) 

The source and target SRNC exchange UTRAN level information (UTRAN classmark,...) and information used to 
ensure that no user packet is lost nor duplicated during the SRNS relocation procedure 
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Figure 4-27: Interface information transfer for SRNS relocation update when changing SGSN area 
resulting in a change of registered location and followed by location registration in new Location 

Area. 

"Resource reservation" Phase 

During this phase, the transmission of packets between GGSN and UE through the source SRNC goes on. 

1) UTRAN (source SRNC) makes the decision to perform the Serving RNC relocation procedure. This 
includes decision on into which RNC (Target RNC) the Serving RNC functionality is to be relocated. The 
source SRNC sends SRNC Relocation required messages to the SGSNl. This message includes parameters 
such as target RNC identifier and an information field that shall be passed transparently to the target RNC. 

2) Upon reception of SRNC Relocation required message the SGSNl determines from the received 
information that the SRNC relocation will (in this case) result in change of SGSN. 

The SGSN will then send a Forwai'd SRNC relocation request to the applicable SGSN, SGSN2, including 
the information received from the Source SRNC and necessary information for the change of SGSN (e.g. 
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MM context, PDP context). The PDP context information contains the list of the PDP context (including 
PDP type, requested / negotiated QoS) currently established by the UE along with the address of the 
associated GGSN. It does not contain any information linked with packet transmission (sequence numbers) 
because such information is under the responsibility of the UTRAN 

3) The SGSN2 sends a SRNC Relocation Request message to the target RNC. This message includes 
information for building up the SRNC context, transparently sent from Source SRNC (e.g. UE id., no of 
connected CN nodes, UE capability information), and directives for setting up lu user plane transport 
bearers. 

When the lu user plane transport bearers have been established, and target RNC completed its preparation 
phase, SRNC Relocation Proceeding 1 message is sent to the SGSN2. The SRNC Relocation Proceeding 1 
message contains the IP address(es) (possibly one address per PDP context) on which the target RNC is 
willing to receive these packets. 

4) When the traffic resources between target RNC and SGSN2 has been allocated and the SGSN2 is ready for 
the SRNC move, then the Forward SRNC Relocation Response is sent from SGSN2 to SGSNl. This 
message indicates that necessary resources have been allocated for the SRNC relocation: SGSN2 / target 
RNC are ready to receive from source SRNC the downstream packets not yet acknowledged by UE. The 
Forward SRNC Relocation Response message contains the IP address(es) that were given in the SRNC 
Relocation Proceeding 1 message. 

5) When the Forward SRNC Relocation Response has been received in the SGSNl, the SGSNl indicates the 
completion of preparation phase at the CN PS domain side for the SRNC relocation by sending the SRNC 
Relocation Proceeding 2 message to the Source RNC. . This message contains the IP address(es) (possibly 
one address per PDP context) on which to send the downstream packets not yet acknowledged by UE. 

'Actual hand-over of Serving RNC" Phase 

6) When the source RNC has received the SRNC Relocation Proceeding 2 message, the source RNC sends a 
SRNC Relocation Commit message to the target RNC(list of (SNU, UP_RLC_ack, SND)). SND is the GTP 
sequence number for the next downlink packet received from the GGSN. SNU is the GTP sequence number 
for the next uplink packet to be tunnelled to the GGSN. UP_RLC_Ack contains the acknowledgements for 
upstream PDU received by the source SRNC on each Non Real Time RLC connection used by the UE (i.e. 
the Receive State Variable V(R) for all RLC SAPI in acknowledged mode). For Real Time connections 
(conversational and streaming QoS class), UP_RLC_ACK is not used. The source SRNC starts a timer T3- 
TUNNEL , stops the exchange of the packets with the UE (point (a)), and starts tunnelling the buffered 
downstream packets towards the target SRNC. The target RNC executes switch for all bearers at the earliest 
suitable time instance. 

7) The target RNC starts acting as SRNC. The target SRNC : 

• Restarts the RLC connections. This includes, for Non Real Time bearers, the exchange between the 
target SRNC and the UE of the UP_RLC_Ack and DOWN_RLC_ACK. DOWN_RLC_ACK confirms 
all mobile-terminated packets successfully transferred before the start of the relocation procedure. If 
DOWN_RLC_ACK confirms reception of packets that were forwarded from the source SRNC, then 
these packets shall be discarded by the target SRNC. UP_RLC Ack confirms all mobile-originated 
packets successfully transferred before the start of the relocation procedure. From now on the exchange 
of the packets with the UE can restart (point (b)). For bearers with header compression, the header 
compression entities renegotiate / restart between UE and target RNC. From now on the exchange of 
data between UE and network can restart. 

• Sends New MM System Information to the UE indicating e.g. relevant Routing Area and Location 
Area. A new RAI triggers a routing area update procedure. Additional RRC information may then also 
be sent to the UE, e.g. new RNTI identity. This may trigger a location update procedure (see 9 and 12) 

8) Immediately after a successful switch at RNC, target RNC (=SRNC) sends SRNC Relocation Detect 
message to the SGSN2. After sending out the New MM System Information, the target RNC sends SRNC 
Relocation Complete message to the SGSN2. 

9) The UE sends a Routing area update request (old RAI; old P-TMSI; old PTMSI signature. Update type) to 
SGSN2 when the New MM System Information included a new RAI. 
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10) Upon reception of RAU request, the SGSN2 updates the GGSN(s) with a Update PDF Context Request 
including the new SGSN address. The GGSN(s) then update the PDF context and return Update PDF 
Context Response. The SGSN2 sends a Complete SRNC Relocation towards the SGSNl. The target RNC 
then receiving downstream packets from both the old path (source SRNC) and from the new path (SGSN2), 
may for RT bearers have too much packets in its queues. The way to discard these packets in excess is 
implementation dependant. 

11) At reception of the Complete SRNC Relocation, SGSNl will send a release indication towards the Source 
RNC. All resources allocated to this UE by the source RNC are released only when this message has been 
received and timer T3-TUNNEL has expired. Before timer T3-TUNNEL expires, all downstream packets 
received from the GGSN are sent towards the target SRNC. 

12) The SGSN2 informs the HLR of the change of SGSN by sending Update GPRS location (IMSl, new SGSN 
address etc.) to the HLR. The HLR cancels the context in the old SGSN, SGSNl, by sending Cancel 
Location (IMSl). The SGSNl removes the context and acknowledges with Cancel Location Ack. The HLR 
sends Insert subscriber data (IMSl, subscription data) to the SGSN2. The SGSN2 acknowledges with Insert 
Subscriber Data Ack. The HLR acknowledges the Update GPRS location by sending Update GPRS 
Location Ack to the SGSN2. 

13) At reception of Insert subscriber data from HLR, the SGSN2 will initiate the update of MM information 
stored in the UE. This is done by sending Network Initiated Routing Area Update Command to the UE. This 
message will include new RAI, and possible also new P-TMSI. When the UE has made necessary updates it 
answers with Network Initiated Routing Area Update Complete. 

14) When receiving new MM system information indicating a new Location Area, the UE will, in this case, 
initiate a Location Area update procedure towards the MSC2. This implies that the Location Area update 
will be performed in parallel to the above indicated activities related to the SGSN side of the Core Network. 

It has to be noted that the sequence chart of Figure 4-27 may be further refined. 

UE-GGSN Communication path during the SRNS relocation procedure 

Before point (a), in Figure 4-27, the connection is established between UE and GGSN via Source SRNC and SGSNl. 



Figure 4-28:Data paths before the SRNS relocation has been actually committed (before point (a) in 

Figure 4-27) 



After transmission of the "SRNS relocation commit" to the target SRNC (after point (a) in figure 4-27), the source RNC 
cannot exchange data with the UE because its RLC should be frozen after the transmission of the RLC sequence 
numbers to the target RNC. Before the restart of the RLC between target SRNC and UE (before point (b) in Figure 4- 
27), data transfer cannot go on. All downstream packets received by the target SRNC during this phase are buffered 
until restart of the RLC between target SRNC and UE. 
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After point (b), in Figure 4-27, packet transfer between UE and network can restart. Upstream packets are sent to 
GGSN via SGSN2 while up to point (c) downstream packets are still sent to the UE via SGSNl, source RNC and target 
SRNC. 

After point (c), in Figure 4-27, the connection is established between UE and GGSN via Target RNC and SGSN2. 

For services requiring high reliability, during T3-Tunnel, the target SRNC listens to the two GTP tunnels at the same 
time and transfers to the UE packets coming from both paths. For RT services, if target SRNC has too much packets in 
its queues (e.g. queues not coherent with maximum transfer delay), the way to discard the packets in excess is 
implementation dependant. 

Before resource release in source RNC (before T3-TUNNEL expiry), target SRNC may receive downstream packet 
from 2 paths. Packets remaining on the backbone are sent on the "old path" (via SGSNl and RNCl) and forwarded by 
source RNCl to target SRNC2 while packets received by the GGSN on its Gi interface are sent on the new path (via 
SGSN2) to target SRNC2. 



Packets 
remaining in 
the 
backbone 




Figure 4-29: Data paths after the GGSN update (after point (c) in Figure 4-27) 




Figure 4-30: Data paths after the resource release in source RNC (after point (d) in Figure 4-27) 

Advantage of this mechanism: 

A common mechanism works for both RT and NRT services. This mechanism works also for GPRS R97 <— > 
UMTS hand-over. 
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The mechanism works for both SRNS relocation and Hand-Over impacting the CN: in the latter case there may be 
no time to prepare the Hand-Over and hence no possibility to request anything (e.g. to duplicate PDU for bi- 
casting) from the GGSN before the commit as e.g. when this Hand-Over impacting the CN corresponds in fact to a 
cell update. 

Drawbacks: 

There are two breaks in transmission (one when the data stream starts from source RNC to target RNC, and one 
when the data stream starts from GGSN via target SGSN) as described in the following figure: speech frames 4,5,6 
sent from the source RNC may be delayed by a few tens of milliseconds, speech frames 7,8 are discarded by the 
target RNC since frames 9, 10 are coming from target SGSN at the same time. So, we have one blank and one 
frame slip. 
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Note: concerns that this might not work properly for RT services have been raised. If the service interruption 
cannot meet service requirements, then a feasibility study could be made on alternative mechanisms to meet 
these requirements for ROO (e.g. bi-casting) . 

4.3.14.3 Comparison between UMTS and GSM 

For the PSTN/ISDN domain, the proposed UMTS MM concept is in principle identical to the GSM MM. 

For the IP domain, the differences between the proposed UMTS MM concept and the GSM GMM are more extensive, 
such as: 

GSM GMM -Ready state where "Cell update" is replaced in UMTS by UMTS PS-CONNECTED state where SGSN is 
maitaining a connection toward UTRAN and the UE location is tracked by UTRAN (i.e. not on MM level). 

GSM GMM-standby state corresponds to UMTS PS-IDLE state. In both case, "Routing area update" is performed and 
SGSN is paging in the routing area. 

A UMTS PS-CONNECTED state is introduced and in this state the UE mobility towards the CN will be handled by 
UTRAN-CN procedures, i.e. not on MM level. 

Figure 4-31 provides illustration of the above bullets. 
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Figure 4-31 The states written in italics correspond to those defined in GSM with GPRS. 



4.3.14.3.1 



PS -idle state 



The RA update procedure is utilised to update the whereabouts of the UE into SGSN. The updating into SGSN takes 
place irrespectively of the CS MM state in MSC. 



4.3.14.3.2 



PS -connected state 



The URA and cell updating and handover procedures presented in Figure 4-31 are based on UMTS YY.03 [2]. In brief, 
the aim in [2] is to introduce functionality that caters for the same functionality as standby/ready in GPRS. The RRC 
shall be designed in such a fashion, which allows the state of the RRC connection to define the level of activity 
associated to a packet data connection. The key parameters of each state are the required activity and resources within 
the state and the required signalling prior to the packet transmission. The operator configurable 

RRC_connection_release timer can be used to release RRC connections in case of very low level of activity and in case 
the QoS requirements e.g. delay requirement allow the release of the RRC connection. 

The cell update and URA update between UE and RNC are used when the UE is in RRC common channel state, i.e., 
when the above mentioned parameters allow to scale down the resources reserved for the UE (for a more detailed 
description on this, see [2]). For example, the purpose of the cell update procedure is to allow the UE to inform its 
current location in the corresponding RRC state. According to [2] the cell update procedure replaces handover in the 
corresponding RRC substate. 

A significant deviation from GPRS is the introduction of the handover procedures for connections supporting traffic 
into IP domain (in RRC cell connected state, see [2]). 

The UE moves to PS-IDLE state in case of expiry of RRC_connection_release timer or an RRC connection failure. 

4.3.1 4.4 Issues for further study 

List of issues that are for further study related to this chapter and is the following: 

More details are required with regards to the differences with regards to the "IP -domain" MM compared to GPRS MM, 
especially considering roaming and handover to/from UMTS to GSM/GPRS. 

More details should be provided with regards to the logical relations between UE-CN and UTRAN-CN, and how these 
relate to the physical interconnection between UTRAN and the CN nodes(s), namely whether one logical/physical lu 
can be used to interconnect the UTRAN with the CN. 

It should be clarified whether this approach allows for the possibility to use a common signalling connection from MSC 
and/or SGSN to the HLR. 
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4.3.1 5 Combined update towards the HLR for a combined 3G- 
(MSC/VLR+SGSN) configuration 

Note: Combined location update procedures are not a high priority architectural requirement for UMTS R99. 



4.3.15.1 



Motivation 



In order to optimise the signalling load within the network, reduce operating and maintenance costs and creating the 
possibility to combine cs and ps handover it is essential to open the door in the specifications for combined 3G- 
(MSC/VLR+SGSN) solutions. 

4.3.15.2 Technical description 

For the area concept discussed for the time being, four different cases have to be distinguished: 

- change of UTRAN Registration Area (URA) within the same Routing Area (RA) 

- change of URA and RA within the same Location Area (LA) 

- change of URA, RA, or LA within the same node 

- change of URA, RA, or LA, and node 

For a combined 3G-(MSC/VLR+SGSN) node only in case 4 the UE's HLR has to be updated. If the UE is idle mode 
for the packet and circuit switched traffic a combined 3G-(MSC/VLR+SGSN) node will run the location update 
procedure jointly for the UE's CS and PS domain resulting in one combined location update message, see Figure 4-32. 




Figure 4-32 Combined lUIIUI Instance For a Combined 3G-(I\/ISC/VLR+SGSN) Node 

Split nodes may have to run one specific location update procedure for any of the two domains resulting in two separate 
location update messages, see Figure 4-33. 
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Figure 4-33 Split MM Instances for Separate Nodes 

4.3.15.3 Requirements on UTRAN 

The provision of location information by the UE to the core network must be independently of whether the 3G- 
MSC/VLR and 3G-SGSN are implemented as separate entities or as a combined node. It shall be possible to use a 
combined update procedure between serving node and HLR irrespective of the update procedure used between the UE 
and the serving node. 

4.3.1 5.4 List of MAP services for location management between the HLR and MSC- 
VLR/SGSN for GSM/GPRS 

Table 1 shows the MAP services used for location management between the SGSN and MSC/VLR and the HLR as 
defined in GSM/GPRS release 98. 



MAP service 


Comment 


MAP_UPDATE_LOCATION 

service 


Updates VLR and MSC number 
in the HLR 


MAP_UPDATE_GPRS_LOCA 
TION service 


Updates SGSN number and 
address in the HLR 


MAP-INSERT-SUBSCRIBER- 
DATA service 


Inserts subscriber data for GSM 
or GPRS 


MAP_SEND_AUTHENTICAT 
ION_INFO service 


To send authentication triplets 
to VLR or SGSN 


MAP_CANCEL_LOCATION 
service 


Cancels location in VLR or 
SGSN 


MAP_PURGE_MS service 


Marks user as unreachable in 
HLR. Common service for both 
GSM and GPRS 
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Table 4-1 : List of Location management services between the HLR and MSC/VLR and SGSN 

From the above table, it is clear that only minor modifications are required to MAP services between the MSC/VLR and 
SGSN and the HLR. A new service combining the MAP_UPDATE_LOCATION and 

MAP_UPDATE_GPRS_LOCATION services will need to be defined. All other services are common for both GSM 
and GPRS and can be used with minor modifications in the "conditional" parameter list. 

4.3.1 5.5 Signalling procedures for combined update towards HLR 

4.3.1 5.6 Combined attach case where the previous attach was towards 2 CN 
elements 



UE 



1. Attach Request 



3. Authentication 



, Attach Accept 



9. Attach Complete 



UMSC 



2Jdentification Response 

4. Update Location for both services 



old SGSN 



2.Identification Request 



HLR 



6. Insert Subscriber Data 

M 



6. Insert Subscriber Data Ack 



5. Cancel Location 



5. Cancel Location Ack 



Ack 



7. Update Location Ack 



old 
MSCA^LR 



5a. Cancel Location 



5a,Cancel Location Ack 



3^ 



Figure 4-34 Combined attach procedure when the lUls moves from 2 CN element to a UIUISC 

1) The UE initiates the attach procedure by the transmission of an Attach Request (IMSI or P-TMSI and old RAI, 
Attach Type, old P-TMSI Signature) message to the UMSC. Attach Type indicates which type of attach that is to be 
performed, i.e., PS attach only, CS attach only, or combined attach (the example given is for combined attach). 

2) If the UE identifies itself with P-TMSI and the 3G-SGSN/UMSC has changed since detach, the new UMSC sends 
an Identification Request (P-TMSI, old RAI, old P-TMSI Signature) to the old SGSN to request the IMSI. The old 
SGSN responds with Identification Response (IMSI, Authentication Triplets). If the UE is not known in the old SGSN, 
the old SGSN responds with an appropriate error cause. The old SGSN also validates the old P-TMSI Signature and 
responds with an appropriate error cause if it does not match the value stored in the old SGSN. 

3) The authentication functions are optional and may be used for example if P-TMSI signature authentication was not 
successftil. If the UMSC number has changed since the detach, or if it is the very first attach, routing/location area 
update procedures are executed: 

4) The UMSC sends a Combined Update Location (UMSC Number, UMSC Address, IMSI) to the HLR. 

5) The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN and MSC. The old SGSN and MSC 
acknowledges with Cancel Location Ack (IMSI). 

6) The HLR sends Insert Subscriber Data (IMSI, PS and CS subscription data) to the new UMSC. The new UMSC 
validates the UE's presence in the (new) RA. If all checks are successful then the UMSC constructs an MM context for 
the UE and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 

7) The HLR acknowledges the Update Location message by sending an Update Location Ack to the UMSC. If the 
Update Location is rejected by the HLR, the UMSC rejects the Attach Request from the UE with an appropriate cause. 
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8) The UMSC sends an Attach Accept (P-TMSI, TMSI, P-TMSI Signature) to the UE. 

9) If P-TMSI or TMSI was changed, the UE acknowledges the received TMSI(s) with Attach Complete (P-TMSI, 
TMSI). 

If the Attach Request cannot be accepted, the UMSC returns an Attach Reject (IMSI, Cause) message to the UE. 

4.3.1 5.7 Combined location/routing area update where the previous LA/RA belonged 
to a 2 CN element 



UE 



UMSC 



1. Routeing Area Update Request 



3. Security Functions 



|5. Forward Packets 



jj . Routeing Area Update 
12. Routeing Area Update 



old SGSN 



2. SGSN Context Request 



2. SGSN Context Response 



4. SGSN Context Acknowledge 



6. Update PDP 
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9. Insert Subsciliber Data 
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9. Insert Subscriber Data Ack 



1 0. Upda 
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Context Reques t 
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7. Combined Update Location 



, Cancel Locaion 



. Cancel Locaion Ack 



late Location Ack 
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-teri. 



old 
MSCA'LR 



8. a. Cancel Location 

► 

. Cancel Locatipn Ack 



Figure 4-35 Combined LA/RA update when the lUIS moves from 2 CN element to UMSC 

The UE sends a Routing Area Update Request (old RAI, old P-TMSI Signature, Update Type) to the new UMSC. 
Update Type example given here is for combined RA / LA update. 

The new UMSC sends SGSN Context Request (old RAI, P-TMSI, old P-TMSI Signature, New UMSC Address) to the 
old SGSN to get the MM and PDP contexts for the UE. The old SGSN validates the old P-TMSI Signature and 
responds with an appropriate error cause if it does not match the value stored in the old SGSN. This should initiate the 
security functions in the new UMSC. 

Security functions may be executed. These procedures are defined in subclause "Security Function". 

If the user has at least one activated PDP context, then the new UMSC shall send an SGSN Context Acknowledge 
message to the old SGSN. This informs the old SGSN that the new UMSC is ready to receive data packets belonging to 
the activated PDP contexts. 

The old SGSN starts tunnelling of buffered N-PDUs to the new UMSC. However, the possibility of this happening is 
remote since the UE is in MM-idle indicating that it was not in active communication. 
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The new UMSC sends Update PDP Context Request to the GGSNs concerned. The GGSNs update their PDP context 
fields and return an Update PDP Context Response (TID). 

The new UMSC informs the HLR of the change of SGSN/MSC by sending Combined Update Location (UMSC 
Number, UMSC Address, IMSI) to the HLR. 

The HLR sends Cancel Location (IMSI, Cancellation Type) to the old SGSN and MSC. The old SGSN acknowledges 
with Cancel Location Ack (IMSI). 

The HLR sends Insert Subscriber Data (IMSI, PS and CS subscription data) to the new UMSC. The new UMSC 
validates the UE's presence in the (new) RA. If due to regional subscription the UE is rejected, the UMSC rejects the 
Attach Request with an appropriate cause and returns an Insert Subscriber Data Ack (IMSI, UMSC Area Restricted Due 
To Regional Subscription) message to the HLR. If all checks are successful then the UMSC constructs an MM context 
for the UE and returns an Insert Subscriber Data Ack (IMSI) message to the HLR. 

The HLR acknowledges the Update Location by sending Update Location Ack (IMSI) to the new UMSC. 

The new UMSC validates the UE's presence in the new RA. If due to regional, national or international restrictions the 
UE is not allowed to attach in the RA or subscription checking fails, then the UMSC rejects the routing area update with 
an appropriate cause. If all checks are successful then the new UMSC establishes MM and PDP contexts for the UE. 
The new UMSC responds to the UE with Routing Area Update Accept (P-TMSI, TMSI, P-TMSI Signature). 

The UE confirms the reallocation of the TMSIs by sending Routing Area Update Complete to the UMSC. 



4.3.16 UTRAN coordination 

The UTRAN coordinates the resource allocation of an UE attached to both PS and CS services. The UTRAN shall 
reject or downgrade a connection which cannot be granted [3]. The cause might be congestion on the radio interface, or 
the existence of other connections between this UE and the other CN. 

The UTRAN use the IMSI to identify a UE. The IMSI is transferred from the Core Network to the UTRAN with the 
common ID procedure. When an lu connection is established, the Core Network shall perform the RANAP common ID 
procedure toward UTRAN as soon as the UE is identified (IMSI). The IMSI is only stored in the UTRAN for the 
duration of the RRC Connection. 

4.4 UIVITS call control 
4.4.1 Technical Requirements 

The following technical requirements are applied to support multimedia in GSM/UMTS. 

PI) GSM/UMTS shall enable the provisioning of multimedia services and multi vendor interworking between 
UE and network. 

P2) Basic voice and PDP-context establishment shall be based on GSM CC/SM respectively. 

P3) Handover and roaming to and from GSM shall be supported provided GSM is capable of supporting the 
ongoing media service. 

P4) Ideas, concepts and procedures developed by other fora e.g. other standards bodies such as ITU, IETF etc. 
shall be included or referenced in GSM/UMTS when found suitable. 

P5) To ensure multi-vendor inter-working and UE roaming, a single standardised multimedia protocol for CS 
domain and a single standardised multimedia protocol for PS domain shall be selected for GSM / UMTS 
R99. This does not preclude the selection of other protocols by UMTS in the future. 

H.323 shall be the multimedia call control model for the PS domain in UMTS R99. 

P6) For multimedia services the standardized multimedia protocol shall be run transparently via a PDP-context 
or a circuit-switched connection established using GSM SM/CC . This allows transparent hand-over and 
roaming between GSM and UMTS provided that GSM supports the QoS requirements. 
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Figure 4-36 illustrates the realisation of the multimedia service based on P6). 'Multimedia Protocol' indicates the 
functionality either inside the communicating user's terminal or a gateway (e.g. H.323 Gateway)/GK. . It is 
essentially a control function both for user plane and control plane for the multimedia communication. 



Multimedia 
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lUlultimedia 
Protocol 



QSIU1SM 
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GSIUISM 



Figure 4-36: Support of multimedia making use of GSIV! SIVI/CC 

Based on the requirements listed above, GSM CC/SM represented by GSM 04.08 forms a solid foundation for UMTS 
CC/SM for Release 99. UMTS CC/SM for Release 99 is to be developed from GSM CC/SM by inti'oducing some well 
defined enhancements. 

Existing (and future) multimedia protocols can be supported by the UMTS CC/SM as application layer protocols, with 
no (or in some instances only minor) impact to UMTS CC/SM. 

4.4.2 Architecture for Multimedia 

In order to include multimedia in release 99 an architecture for multimedia is required. Sections 4.4.2.1 and 4.4.2.2 
below detail the architecture for UMTS multimedia. It is recognised that it may not be possible to include all the 
functionality included in this architecture in release 99. 

4.4.2.1 Packet Switched Domain 
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Figure 4-37: Multimedia architecture PS Domain 

The multimedia C-plane and U-plane are run transparently over a PDP-context between the UE and multimedia 
gatekeeper and gateway. 

The multimedia U-plane runs between the UE and the multimedia gateway. The multimedia gateway maps the 
multimedia U-plane on to the U plane in the external network eg. Internet, PSTN. In some cases, such as a UMTS to 
UMTS call this may unnecessary. 

The multimedia control protocol is run between the UE and multimedia gatekeeper. The multimedia gatekeeper is 
responsible for establishing a multimedia C plane connection on the terminating network. 

The service capability server is functionally distinct from the multimedia gatekeeper. It is responsible for creating 
multimedia services. The standardisation of the interface between the service capability server and the multimedia 
gatekeeper is for further study. The service capability server may require interfaces to the HLR and CSE (Camel 
Service Environment) in order to enable interactions between multimedia services and the services provided by these 
platforms. In this case the interfaces X and Y in Figure 4-37 will require standardisation, (It is not proposed that this be 
included in release 99). The handling of MT communications is for further study. 

Services can be delivered at two levels: 

• Bearer level services are those which correspond to the UMTS bearer service and are delivered via the 

SGSN, HLR and CSE. Examples of bearer level services are pre-paid or barring of PDP context 
establishment (for the UMTS bearer service). 

• Multimedia level services are delivered via the multimedia gatekeeper and service capability server possibly 

in combination with the HLR and CSE. Examples of multimedia services are video conferencing, call 
forwarding and pre-paid (of the multimedia component). 
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The multimedia gatekeeper and service capability server may be located within or external to the UMTS PLMN. The 
implications of the location of the multimedia gatekeeper and service capability server are for further study. 

4.4.2.2 Circuit Switched Domain 
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Figure 4-38: Multimedia architecture CS Domain 

The multimedia C-plane and U-plane are run transparently over a bearer between the UE and destination or optionaly 
the multimedia gatekeeper and/or gateway if present. 

The multimedia U-plane runs between the UE and destination. Optionaly the multimedia U-plane is terminated at the 
the multimedia gateway, which interworks with the external network. 

The multimedia control protocol is run between the UE and the destination. Optionally the multimedia gatekeeper is 
responsible for establishing a multimedia C plane connection on the fixed network. 

The service capability server is functionally distinct from the multimedia gatekeeper. It is responsible for creating 
multimedia services. The standardisation of the interface between the service capability server and the multimedia 
gatekeeper is for further study. The service capability server may require interfaces to the HLR and CSE (Camel 
Service Environment) in order to enable interactions between multimedia services and the services provided by these 
platforms. In this case the interfaces X and Y in Figure 4-38 will require standardisation, (It is not proposed that this be 
included in release 99). The handling of MT communications is for further study. 

Services can be delivered at two levels: 
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• Bearer level services are those which correspond to the UMTS bearer service and are delivered via the MSC, 

HLR and CSE. Examples of bearer level services are pre-paid or call barring (for the UMTS bearer 
service). 

• Multimedia level services are delivered via the multimedia gatekeeper (if present) and service capability 

server possibly in combination with the HLR and CSE. Examples of multimedia services are video 
conferencing, call forwarding and pre-paid (of the multimedia component). If there is no multimedia 
gatekeeper network level multimedia services can not be provided. 

The multimedia gatekeeper and service capability server may be located within or external to the UMTS PLMN. The 
implications of the location of the multimedia gatekeeper and service capability server are for further study. 

4.4.3 Typical Scenarios for Multimedia Control and User Plane 

Two typical call scenarios to support multimedia services, H.324 and H.323, respectively, are presented as examples. 
As an assumption, the calls are between the peer multimedia terminals over an IMT-2000 network. As shown in the 
following sections, the multimedia signalling protocol and data transmission for both call scenarios can be performed 
end-to-end on the IMT-2000 user plane and is thereby transparent to the IMT-2000 Core Network. The IMT-2000 
operators still control the multimedia service towards the end-user by providing the service via a service node (gateway, 
gatekeeper or application server) inside its own domain. Some other call scenarios e.g. IMT-2000 to ISDN/PSTN and/or 
IMT-2000 to the IP network can also be illustrated in a similar fashion. 



4.4.3.1 



H.324M to H.324M Call 



In Figure 4-39, the H.324M IMT-2000 terminal initiates the call set-up procedure by sending a 04.08 SET-UP message 
to the originating MSC/VLR. 

After the received 04.08 SETUP message, the originating MSC/VLR sends an ISUP Initial Address Message (lAM) to 
the terminating MSC/VLR. The terminating MSC/VLR performs a 04.08 SETUP procedure towards the H.324M 
UMTS terminal. The communication link is now established between the two H.324M endpoints. 

The logical channels can now be established using the H.245 open logical channel procedure. 

No gateway is needed in this case. This case is simple to support and requires little standardization. 

The 04.08 Bearer Capability is used to indicate 64 kbits/s bit transparent case described in GSM 07.01 can be used, as 
well as H.223/H.245. 

The 04.08 LLC is used to indicate H.223/H.245. This makes the called IMT-2000 mobile terminal activate its H.324M 
application when receiving the SETUP (LLC:H.223/H.245). 
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4.4.3.2 



Figure 4-39: UMTS H.324M - UMTS H.324M call example 



IMT-2000 H.323 to H.323 call 



Figure 4-40 shows a Multimedia Call between two H.323 terminals within an IMT-2000 operator domain. It is assumed 
that a PDP Context using a Best Effort (BE) Radio Access Bearer (RAB) from terminal A towards the Gatekeeper (GK) 
and one from terminal B towards GK have already been established for H.323 registration in this figure. Terminal A 
and B now performs Gatekeeper Identification and Gatekeeper Registration using a BE RAB. Thereafter, the terminal A 
sets up a Real Time (RT) Radio Access Bearer (RAB) to decrease the time for the H.323 control signalling. This need 
of a Real Time Radio Access Bearer can be indicated from the terminal application to the mobile terminal through the 
Application Programming Interface (API). The terminal A performs PDP Context activation (see Figure Z) to set up the 
Real Time Radio Access Bearer. From now on, the established Real Time Radio Access Bearer can be used for H. 225.0 
RAS control signalling and Q.931 control signalling. After the Real Time Radio Access Bearer is established, the H.323 
terminal A performs an Admission Request (ARQ) towards the Gatekeeper. If the terminal A is admitted the 
Gatekeeper answers with AdmissionConfirm (ACF) otherwise AdmissionReject (ARJ). Terminal A initiates the H.323 
connection by sending a Q.93 1 Setup message to the Gatekeeper when the ACF has been received. The Gatekeeper 
answers with a Q.931 Call Proceeding to terminal A and sends a Q.931 Setup message to terminal B on a Best Effort 
(BE) Radio Access Bearer (RAB). Terminal B performs PDP Context Activation to SGSN and GGSN to set up a Real 
Time Radio Access Bearer and performs an Admission Request towards the Gatekeeper on this Real Time Radio 
Access Bearer. After this terminal B answers the received Q.93 1 Setup message with a Q.93 1 Alert and Connect 
message to the Gatekeeper on receipt of the Admission ConFirm (ACF) message. The Gatekeeper forwards these two 
messages to the terminal A. The Real Time Protocol (RTP) is now established between the terminal A and B for 
transmission of audio, video or data streams (see Figure 4-40). The Gatekeeper relays the data streams but is not 
always completely transparent. The Gatekeeper can perform interworking functions e.g. Network Address Translation 
(NAT) etc between different networks. The voice transcoding is performed end-to-end in the H.323 terminal. 
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Figure 4-40: IMT-2000 H.323 - H.323 call example 



4.5 Core network layer 3 



In UMTS/GPRS, it should be possible for operators to use different packet switching protocol (e.g. ATM-SVC) under 
single GTP standard. 

Between GSNs GTP uses UDP/IP (or TCP/IP) for addressing regardless whether IP routing or ATM-SVC switching is 
used. The use of ATM-SVC will not impact on GTP standardisation. " 
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Figure 4-41 : Core network layer 3 



4.6 Structure of radio interface layer 3 

The signalling plane consists of protocols for control and support of the transmission plane functions. The following 
signalling planes are used in UMTS between UE and 3G-SGSN. 
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Figure 4-42: Protocol Architecture for radio interface layer 3 towards the PS service domain 

UMTS PS service domain Mobility Management and Session Management (GMM/SM): This protocol supports 
mobility management functionality such as PS attach, PS detach, security, routing area update, location update, PDP 
context activation, and PDP context deactivation. 

4.7 Alternate Access technologies to UTRAN 

BRAN Access 

The evolved GPRS network should allow for various radio access networks. As stated in [UMTS 23.101], a modular 
approach in UMTS evolution is recommended. This is also in line with the recommendation from GMM. Thus, the 
infrastructure domain, which encompasses the core network domain and the access network domain, allows for 
different access techniques/networks to be used. This scenario focuses on EP BRAN HIPERLAN 2 as a complement to 
GSM BSS and UTRAN in order to provide broadband data services in hot spot environments. 

ETSI Project BRAN (Broadband Radio Access Networks) is developing specifications for broadband wireless access 
systems that support data rates around 25 Mbit/s for several applications. The primary focus for HIPERLAN 2 is to 
provide short range wireless broadband access with controlled quality of service for use within buildings and on- 
campus using unlicensed radio spectrum in the 5 GHz band. HIPERLAN 2 shall provide a range of 30-50 m in a typical 
indoor environment and up to 150-200 m in a typical outdoor environment. 
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The HIPERLAN 2 specifications are expected to be finalised during 2000, hence it will be possible to introduce BRAN 
access in UMTS phase 1. 

4.7.1 Advantages of attaching HIPERLAN 2 to UMTS 

Provide UMTS with a complementary access technology for broadband data services for indoor and hot spots 
environments 

UMTS mobility infrastructure enables roaming also for HIPERLAN 2 terminals 

Easier multi-mode UMTS/HIPERLAN 2 service integration, enables e.g. network support for a one number service and 
the use of a common service platform 

UMTS subscriber management may be reused for HIPERLAN 2 

Enables the reuse of investments in core network technologies. 

4.7.2 HIPERLAN 2 UMTS Interworking 

UMTS will incorporate a new generic radio access network, the UMTS Radio Access Network (URAN). The URAN 
may include several different realisations, of which the UTRAN (UMTS Terrestrial Radio Access Network) is one. The 
lu reference point forms the boundary between URAN and the UMTS core network. By connecting HIPERLAN 2 to 
the lu interface, HIPERLAN 2 will form a complimentary realisation of the URAN concept for broadband data services. 
UMTS interworking will provide HIPERLAN 2 with roaming support using the UMTS mobility infrastructure. 




AFt lAPt JAFt 



Figure 4-43: HIPERLAN 2 UMTS interworking. 

A HIPERLAN 2 realisation of URAN should provide the same logical interface to the higher layers (i.e. layers 
belonging to the non-access stratum) as UTRAN. Hence, no changes in higher layers should be required. UMTS 
authentication, security and location management can be used over HIPERLAN 2. UMTS bearer setup requests should 
be mapped to the corresponding HIPERLAN 2 DLC connection. A USIM (User Service Identity Module) may be 
needed in a BRAN terminal supporting UMTS interworking. Handovers within a HIPERLAN 2 subsystem should be 
invisible to the core network. Handovers between UTRAN and HIPERLAN 2, in case of dual mode terminals, should 
be supported via the core network. 

4.7.3 Related Actions 

The same protocols over the lu interface should be used for both UTRAN and HIPERLAN 2. However, some impact of 
connecting a broadband access network, capable of bit rates in the order of 100 Mbit/s, can be expected. Therefore the 
lu must be flexible and future proof. Guidance and co-operation with EP BRAN on these matters should be sought. 
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4.8 Location of the IP compression function in UIVITS 
4.8.1 Functional role of SNDCP / L3CE 

Out of the functions devoted to SNDCP in 2G network, only header compression and XID negotiation functions need to 
be considered in UMTS. Hence the term L3CE is introduced. 



Figure 4-43bis: Compression Entity Functionality for UMTS 



4.8.2 Position for header compression 



RNC position for header compression is the best place because: 

differential header compression algorithms work better if they are located in the place where packets are more likely to 
be discarded (after having discarded packets the compression algorithm can send a packet with full header^). This place 
is the RNC (where the queues for downstream packets waiting for radio resources are located). 

The compression entity is as close as possible to the reliable link (as in 2G) which in this case is the RLC. Therefore it 
can be stated that a faster recovery of packets is possible after loss of packets in the radio interface and this solution will 
therefore minimize the amount of buffering in the UE and network. 

the compression can be optimized for the used RAN. 

It increases the possible data rates that can be achieved: Locating the compression function in the RAN defers the 
SGSN from the task of opening and processing packets 

efficient inter-system hand-over can be supported 
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4.8.3 Implied protocol stack 
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Figure 4-44: User Plane Protocol Architecture with header compression mechanisms 

4.9 Short Message Service for UMTS 

UMTS will continuously support Short Message Service which already exists for GSM/GPRS system. 

4.9.1 Protocols and architecture 

The LLC layer is only applicable for GPRS and not for UMTS. Due to that, there is a need to reconsider the 
functionality which is done at LLC in GPRS. There are two alternative described below. 

• Use U-plane as the alternative of LLC functionality. 

• Use C-plane as the alternative of LLC functionality. 

It is too much to establish U-plane connection to transfer small amount of data when focusing on the resource of the 
entire system. 

If C-plane was used for data transfer, it can save resource compared with establishing U-plane connection(by using 
common channel, efficient use of radio resource is possible). It also possess the advantage of making it possible to use 
same SMS transfer procedure for CS domain and PS domain. Therefore, it comes to a conclusion that the C-plane shall 
be used for SMS transfer in UMTS system. 

The C-plane is a signalling connection between UE and MSC or SGSN, respectively. Establishment of a secure 
signalling connection is offered by the GMM in the PS domain and by the MM in the CS domain. SMS is a user of that 
secure signalling connection. 
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Figure 4-45: Protocol architecture for 3G SMS for both a CS service domain and a PS service domain 

4.10 Cell Broadcast Service in UIVITS 

The Cell Broadcast Service (CBS) is defined as a UMTS R99 requirement to guarantee the continuity of the 
corresponding GSM services. It shall be provided seamlessly (as far as the user or the users terminal equipment is 
concerned) across the UMTS and GSM network. 

4.10.1 Network Architecture 

Figure 4-45a proposes a straight forward adoption of the GSM cell broadcast architecture in UMTS. 

The basic network structure replaces the GSM BSS with the UTRAN containing the RNC and the Node B. The cell 
broadcast center (CBC) is part of the core network and connected via the Be reference point to the RNC. On the logical 
interface between the CBC and the RNC a mandatory protocol shall be defined to meet the requirements defined in 
3GPP TS 23.041. Based on this architecture and the current requirements for cell broadcast the core network elements 
like MSC, VLR, HLR etc are not involved for the service delivery. 



UE 



UE 



Uu 



UTRAN 



NodeB 



NodeB 



RNC 



lub 




Figure 4-45a: Architecture for the Cell Broadcast Service in UMTS 

Be is the reference point between the CBC and the RNC. The protocol stack between the CBC and the RNC is given in 
figure 4-45b. 
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Figure 4-45b: Protocol architecture for the Cell Broadcast Service 

CB Appl 1 provides the description of the information passed from the CBC to the UE at the highest layer. This is not 
changed by the RNC. CB Appl. 2 provides the lower level UE function and CB Appl 3 runs between the CBC and 
RNC. The protocol primitives of the CB application are described in TS23.041. 

The Layer 4 between RNC and CBC (UDP or TCP) shall be selected depending on the requirements of the CB 
Application 3. 

It should be possible for one CBC to reach every RNC of one PLMN. It should be possible that an RNC is connected to 
at least two CBC at the same time (the "normal" one as in GSM and a second one for LCS). 

Note that even if CBS is supported by a separate protocol suite over the Be reference point it shall be possible to share 
the transport resources of the lu interface (i.e. ATM/AAL5/IP) as shown in Figure 4-45c. 
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Figure 4-45c: Possible mapping of the Be reference point onto the transport resources of the lu 

interface 

4.1 Mobile IP for UMTS/GPRS End Users 
4.10.1 Mobile IP for UMTS/GPRS End Users 

A single generic mobility handling mechanism that allows roaming between all types of access networks would allow 
the user to conveniently move between fixed and mobile networks, between public and private as well as between 
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PLMN's with different access technologies. The ongoing work in IETF Mobile IP working group [13] is targeted 
towards such a mechanism^ and a set of standards are planned to be finalized during 1999. Thus, it is important to offer 
Mobile IP also to UMTS and GPRS users to allow them to roam to and from other access technologies while keeping 
ongoing data sessions, e.g. TCP or UDP. A typical UMTS network supporting Mobile IP is shown in Figure 4-46. 
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Figure 4-46. Core network architecture with GPRS IVIIVI within the PLIVIN's and IVIobile IP MM between 

different types of systems. 

As IP addresses in IPv4 are scarce, it has to be assumed that Mobile IPv4 preferably will be used with the Foreign 
Agent (FA) care-of addresses [10]. Compared to using co-located care -of addresses, FA care-of addresses does not only 
conserve IP addresses, it is also more efficient over the radio interface. We assume here that the MS keeps the same 
care-of address as long as the PDP context is activated, i.e. does not change GGSN/FA during a UMTS/GPRS session. 
It is further assumed that PDP type "IP" is used. It is, however, likely that PDP type" PPP" also could be used. Roaming 
between PLMN's can be realized with GPRS roaming or Mobile IP. 

To offer Mobile IP with FA care-of addresses over the UMTS/GPRS network, some requirements need to be fulfilled. 
Some of these will cause changes to the current GPRS standards. 

A signaling scheme, shown in figure 4-47, is described below. The PPP setup and the UMTS/GPRS attach procedures 
and "GGSN-Initiated PDP Context modification procedure" have been omitted for clarity. 



-2 

■^ Note that in this text, Mobile IP is used in a wide sense. It refers to [10] and the RFC's planed to be finahzed this year. 
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IPv4 - Registration UMTS/GPRS + MIP , FA care-of address 
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Figure 4-47. PDP Context activation with lUlobile IP registration (the PPP setup and UMTS/GPRS 

attach procedures not included) 

1. The AT command carries parameters that the MT needs to request the PDP Context Activation. The important 
parameter here, is the APN (Access Point Name), see section A below. The AT command is followed by a setup of the 
PPP connection between the MT and the TE, which are not included in the figure. 

2. The MT sends the "Activate PDP Context Request" to the SGSN. The message includes various parameters of which 
the "APN" (Access Point Name) and the "Requested PDP Address" are of interest here. The MS may use APN to select 
a reference point to a certain external network and/or to select a service. APN is a logical name referring to the external 
packet data network and/or to a service that the subscriber wishes to connect to. The "Requested PDP Adress" should 
be omitted for all MS's using Mobile IP. This is done irrespective of if the MT has a permanently assigned Mobile IP 
address from its Mobile IP home network, a previously assigned dynamic home address from its Mobile IP home 
network or if it wishes the Mobile IP home network to allocate a "new" dynamic home address. 

A. The SGSN will base the choice of GGSN on the APN that is given by the MS. 

The APN consists of two parts: the Network ID and the Operator ID. If no APN is given and PDP type is "IP", the 
SGSN chooses a suitable GGSN according to operator's configuration of the SGSN. Similarly, a Network ID of the 
format vvv (one label, no dots) can be used to specify any GGSN with a specific service (vvv), e.g. Internet access, 
gateway for voice over IP, Mobile IP FA. If the SGSN is not configured to identify the requested service it may try with 
a DNS interrogation for vvv.current-operator.current-country.gprs or, if that is not successful, with vvv.home- 
operator.home-country.gprs, where the home parameters are taken from the subscription data. 



3. The SGSN requests the selected GGSN to set up a PDP Context for the 
the same as in the "Activate PDP Context Request" message. 



MS. The PDP address and APN fields are 
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4. A Create PDP Context Response is sent from the GGSN/FA to the SGSN. If the creation of PDP Context was 
successful, some parameters will be returned to the SGSN, if not, error code will be returned. If the GGSN has been 
configured by the operator to use a Foreign Agent for the requested APN, the PDP adress returned by the GGSN shall 
be set to 0.0.0.0. indicating that the PDP adress shall be negotiated by the MS with a Home Agent after the PDP context 
activation procedure. 

5. The Activate PDP Context Accept message is sent by the SGSN to the MS and contains similar information as the 
Create PDP Context Response message. 

6. The Agent Advertisement [10] is an ICMP (Internet Control Message Protocol) Router Advertisement message with 
a mobility agent advertisement extension. The latter part contains parameters of the FA that the mobile node needs, 
among those are one or more care-of addresses that the FA offers. This message should be sent, in the UMTS/GPRS 
user plane, as an IP limited broadcast message, i.e. destination address 255.255.255.255, however only on the TID for 
the newly arrived MS to avoid broadcast over the radio interface. 

7. The Mobile IP Registration Request is sent from the mobile node to the GGSN/FA across the GPRS/UMTS 
backbone as user traffic. The mobile node includes its (permanent) home address as a parameter [10]. Alternatively, it 
can request a temporary address assigned by the home network by including the Network Access Identifier (NAJ) in a 
Mobile-Node-N AI Extension [ 1 2] [ 1 1 ] . 

8. The FA forwards the Mobile IP Registration Request to the home network of the mobile node, where it get processed 
by a Home Agent (HA). Meanwhile, the GGSN/FA needs to store the home address of the mobile node or the NAI and 
the local link address of the MS, i.e. the TID (GPRS Tunnel ID). 

9. The Registration Reply is sent from the home network to the FA, which extracts the information it needs (e.g. the 
home address of the mobile node if allocated by the home network). 

10. The FA forwards the message to the mobile node in the UMTS/GPRS user plane. As the FA/GGSN knows the TID 
and the NAI or home address, it can pass it on to the correct MS. A home adress of the MS allocated by the home 
network is sent to the SGSN by means of the "GGSN-Initiated PDP Context modification procedure" described in 
[23.060] 

4.1 0.1 .1 Alterations of and Additions to Current GPRS Standards 

To support Mobile IP as described above, the following alterations and additions to the GPRS specifications are 
necessary: 

1. The functionality of the GGSN needs to be enhanced with FA functionality, according to IETF specifications. For 
interoperability, a set of RFC's should be recommended. There is no need to standardize an interface between the 
GGSN and the FA, as it is considered being one integrated node. 

2. The GGSN/FA node should send a FA Advertisement message after sending the Create PDP Context Response. 

3. The GGSN should not give the MS a temporary UMTS/GPRS IP (PDP) address if the Mobile IP FA service has been 
requested. 

4. The GGSN/FA and the MS shall exchange Mobile IP signahng messages in the UMTS/GPRS user plane. 

5. Allow the APN to mean a GGSN with a specific service, not only a physical node. To support this, the operator must 
have the possibility to configure the SGSN or DNS with the choice of GGSN depending on service. A default 
mechanism is also needed to use a GGSN in the MS's home network if the visited SGSN does not support the requested 
service. Finally, an agreement between operators is needed on the possible APN's. 

4.1 1 Allowed network and terminal configurations 

A UMTS network is divided into a radio access network and a core network, which are connected via an open interface 
over the lu reference point. Furthermore, the core network is from a functional point of view divided into a Packet 
Switched Service Domain and a Circuit Switched Service Domain. 

The following network configurations shall be allowed: 

a) Networks which provide the functionality of CS Service Domain and PS Service Domain. 
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b) Networks which only provide the functionaUty of the CS Service Domain. 

c) Networks which only provide the functionality of the PS Service Domain. 
The following terminal configurations shall be allowed: 

a) Terminals which are able to access both to the CS Domain and PS Domain. 

b) Terminals which are only able to access to the PS Domain. 

c) Terminals which are only able to access to the CS Domain. 

It shall be noted that e.g. terminal which is only able to access to the PS Domain supports only mobility management, 
protocols etc. of that particular domain. The different configurations given above shall not prevent CS-type services 
from being delivered over the PS domain. 

5 UMTS to UMTS handover for circuit switched 
services 

For UMTS to UMTS Inter-MSC Handover the GSM E i/f transporting BSSAP messages with necessary modifications 
for GSM to UMTS Handover shall be used. 

[Ed note: signaling flows are to be provided and be in line with "GSM to UMTS handover for circuit switched 
services"] 

6 Interoperability between GSM and UMTS 

• Transparency [from a users perspective] of roaming and handover 

• Re-use of existing subscription profiles 
Note: This list is not exhaustive and is FES. 

This allows easier management and deployment of a new UMTS network. 

UMTS is a system supporting handovers between GSM and UMTS in both directions. To support these handovers 
effectively, the following is required from a dual mode MS/UE supporting simultaneous ISDN/PSTN and packet 
service in GSM/UMTS: 

Depending upon the solution adopted for GSM-UMTS handover, the MS/UE supporting simultaneous ISDN/PSTN and 
packet service may be required to perform appropriate update into CN depending on the activity of the UE once the 
handover between GSM and UMTS is completed. This update is needed to avoid any severe interruptions on the 
accessibility of packet services after the handover. 

The nature of the update to be made after the handover in both direction, i.e., from GSM to UMTS and from UMTS to 
GSM, from MS/UE depends on the activity of the UE in the following way: 

ISDN/PSTN connection: RA update only (if RA is changed) 

Packet connection: LA and RA update (if RA and LA are changed) 

Both ISDN/PSTN and packet connection: RA update only (if RA is changed) 

If the RA, LA or both LA and RA are not changed the MS/UE behaviour is for further study 

6.1 Circuit Switched Handover and Roaming Principles 

Introduction of a UMTS Core Network necessitates the inter-connection with legacy systems to allow inter-PLMN 
roaming and handover. 
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For ease of convergence with the existing networks and the introduction of dual mode handsets, roaming and handover 
to/from UMTS should be performed in the simplest manner that requires as little change as possible to the legacy 
networks and standards, i.e. inter-MSC handover functionality. 

These principles provide - from a user perspective - transparency of handover and roaming. In addition, operators 
providing UMTS services should also allow access to legacy networks using existing subscriber profiles and network 
interfaces. 

Illustrated in Figure 6-1 shows the introduction of a UMTS Core Network for UMTS phase 1 network configuration. 
Notice that it leaves the current GSM specifications mainly untouched whereupon the UMTS core network acts towards 
the GSM MSC like a GSM MSC by providing for example MAP/E for handover purposes. Further, it should be 
observed that GSM subscriptions belong to the HLR whilst UMTS subscriptions exist in the HLR release 99.. 
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Figure 6-1 Inter-Operability between GSM and UMTS 

Note: No physical implementation should be taken from the figure. As a further note, no interworking functions are 
shown to ease clarity, but however should not be precluded. 

From Figure 6-1 it can be seen that the information exchanged over the lu must provide the necessary parameters to 
enable the core networks to communicate via for example the MAP interface for handover purposes. 

Also note that from the above diagram, existing interfaces are used towards the HLR to allow for subscription 
management based on today's principles using the already defined user profile, providing seamless roaming between 
the 2'"' generation system and UMTS. 

The existing GSM handover procedures should be re-used to minimise the effects on existing GSM equipment. 

• The anchor concept in GSM for inter-MSC handover should be used for inter-system handover between UMTS and 
GSM. 

• The signalling over the A-interface and over the MAP/E-interface should be the same as in GSM 
phase 2h- with possibly addition of some new or updated information elements in some messages. 

• For the set up of the handover leg (user plane) standard ISUP/POTS should be used in line with the principles used 
in GSM. 

• The control signalling over the lu-interface at handover between UMTS and GSM should be based on the A- 
interface signalling at inter-MSC handover in GSM. 
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• 



• 



• 



The signalling over the lu-interface at call set up to/from a dual mode UMTS/GSM mobile station, shall include 

GSM information elements needed for handover from UMTS to GSM. 

In the corresponding way the signalling over the A-interface at call set up to/from a dual mode UMTS/GSM mobile 

shall include UMTS elements needed for handover from GSM to UMTS. 

The data are needed to initiate the handover towards the new BSS/RNC. 

A target cell based on CGI is sent to the MSC from UTRAN at handover from UMTS to GSM. The CGI points out 
the target MSC and target BSC. 

A target cell based on CGI is sent to the MSC from the BSS at handover from GSM to UMTS. The CGI points out 
the target UMTS MSC and target RNC (UMTS MSC does the translation from CGI to RNC identity). 



6.1 .1 UMTS to GSM handover for circuit switcinecJ services 

The signalling sequence in Figure 6-2 shows the case when the UMTS MSC (UMSC) and the GSM MSC are located in 
separate "physical" nodes. 

If the UMSC and MSC are located within the same "physical" node, no MAP signalling and no ISUP signalling are 
needed between UMSC and MSC. 

For release 99 it is expected that the codec is placed in the anchor or non-anchor UMSC (for the UE in UMTS mode), 
which will have no impact on the signalling. 
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Figure 6-2. UMTS to GSM handover for circuit switched services e.g. voice 

1) SRNS initiates the preparation of UMTS to GSM Handover by sending the RANAP message Relocation 
Required to UMSC. This message includes parameters such as Target cell identification and Serving cell 
identification, both in the form of CGI according to GSM. 

2) UMSC requests MSC to prepare for UMTS to GSM Handover, by sending the MAP message PREPARE 
HANDOVER request. The message contains a BSSMAP message Handover Request, to be sent from MSC 
to BSS. It includes data such as Target and Serving CGI received from the Relocation Required message, and 
data stored in UMSC indicating type of radio resources required. 

3) MSC sends the BSSMAP message Handover Request to BSS which then allocates necessary radio resources 
in BSS. 

4) When BSS has allocated necessary radio resources it sends the BSSMAP message Handover Request 
Acknowledge. This message contains all radio-related information that the UE needs for handover, i.e. a 
complete GSM Handover Command message to be sent transparently via MSC, UMSC, and SRNS to UE. 

5) MSC acknowledges handover preparation by sending the MAP message Prepare Handover Respons to 
UMSC, including a complete GSM Handover Command message. 
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6) UMSC sends the ISUP message lAM to MSC to establish a circuit ISUP connection between UMSC and 
MSC. 

7) As acknowledgement to lAM, MSC sends the ISUP message ACM back to UMSC. 

8) UMSC sends the RANAP message Relocation Command to SRNS, including a complete GSM Handover 
Command message to be sent to UE. 

9) SRNS sends the RRC message Handover Command to UE, including a complete GSM handover Command 
message, to order the UE to start the execution of handover. 

10) Upon detection of UE in BSS, (by reception of the Layerl GSM message Handover Access from the UE), 
which indicates that the correct UE has successful accessed the radio resource in the target GSM cell, the 
BSSMAP message Handover Detect is sent from BSS to MSC. MSC may use this condition to switch the 
connection to the BSS. 

1 1)MSC sends the MAP message PROCESS-ACCESS-SIGNALLING request to UMSC, including the 
BSSMAP message Handover Detect. UMSC may use this message as trigger point for switch of the 
connection to the MSC. 

12)To complete the ISUP signalHng the ISUP message ANM is sent from MSC to UMSC. 

13) After Layer 1 and 2 connections are successfully established, the UE sends the GSM message Handover 
Complete to BSS. 

14) After completed handover, BSS sends the BSSMAP message Handover Complete to MSC. 

15)MSC sends the MAP message SEND -END- SIGNAL request to UMSC, including the BSSMAP message 
Handover Complete. 

16) UMSC initiates release of resources allocated by the former SRNS. 

17)SRNS acknowledges release of resources. 

6.1 .2 GSM to UMTS handover for circuit switclned services 

The signalling sequence in figure 6-3 shows the case when the UMTS MSC (UMSC) and the GSM MSC are located in 
separate "physical" nodes. 

If the UMSC and MSC are located within the same "physical" node, no MAP signalling and no ISUP signalling are 
needed between UMSC and MSC. 

For release 99 it is expected that the codec is placed in the anchor or non-anchor UMSC (for the UE in UMTS mode), 
which will have no impact on the signalling. 
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Figure 6-3. GSM to UMTS handover for circuit switchied services e.g. voice 

1. BSS initiates the preparation of GSM to UMTS Handover, by sending the BSSMAP message Handover Required 
to MSC. This message includes parameters such as Target cell identification as CGI, and information to be sent 
further transparent to Target RNC via MSC and UMSC. 

2. MSC requests UMSC to prepare for GSM to UMTS Handover, by sending the MAP message PREPARE 
HANDOVER Request. This message includes parameters such as Target cell identification and Serving cell 
identification, both in the form of CGI, and information to be sent transparent to the Target RNC via UMSC. 

3. UMSC requests Target RNC to prepare for GSM to UMTS Handover, by sending the RANAP message Relocation 
Request. UMSC translates the Target cell identification (CGI) received in the MAP message PREPARE 
HANDOVER Request, to a RNC pointer to address the Target RNC. This message includes parameters such as 
bearer related information, and information received in the MAP message Prepare Handover Request to be sent 
transparent to the Target RNC. 

4. When Target RNC has allocated necessary radio resources it sends the RANAP message Relocation Request 
Acknowledge to UMSC. This message contains all radio-related information that the UE needs for handover, i.e. a 
complete RRC message to be sent transparently via UMSC, MSC and BSS to the UE. 

5. UMSC sends the MAP message PREPARE HANDOVER Response to MSC including a complete 
RRC message, to be sent transparent to UE via MSC and BSS. 
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6. MSC sends the ISUP message lAM to UMSC to establish a circuit ISUP connection between MSC and UMSC 

7. As acknowledgement to lAM, UMSC sends the ISUP message ACM back to MSC. 

8. MSC sends the BSSMAP message Handover Command to BSS, including a complete RRC message to be sent 
transparent to UE via BSS. 

9. BSS sends the GSM message Handover Command to UE including a complete RRC message, to order the UE to 
start execution of handover. 

10. Upon detection of the UE in Target RNC, Target RNC starts acting as SRNC for the UE, and the RANAP message 
Relocation Detect is sent from RNC to UMSC. 

1 1 . At reception of the RANAP message Relocation Detect, the UMSC sends the MAP message PROCESS -ACCESS 
SIGNALLING Request to MSC. MSC may use this message as trigger point for switch of the connection to the 
UMSC. 

12. To complete the ISUP signalHng the ISUP message ANM is sent from UMSC to MSC. 

13. After completed handover, UE sends the RRC message Handover Complete to Target RNC. 

14. Target RNC sends the RANAP message Relocation Complete to UMSC. 

15. UMSC forwards the RANAP message Relocation Complete in the MAP message SEND END SIGNAL Request to 
MSC. 

16. MSC initiates release of resources allocated by BSS. 

BSS acknowledges release of resources. 

6.2 Packet Switched Handover and Roaming Principles 

The introduction of a UMTS core Network illustrates the requirement for inter-connection with the legacy GSM system 
to allow inter-PLMN roaming and handover. 

Even though there is no current GPRS deployment, the operator may decide to deploy a GPRS network prior to the 
deployment of a UMTS network. Therefore, the introduction of a UMTS Core Network may require to be inter- 
connected to the legacy packet network. 

As in the circuit switched case, roaming and handover to/from UMTS should be performed in the simplest manner that 
requires as little change as possible to the GPRS network and standards, i.e. inter-GSN handover functionality. In 
addition, access is provided to the GPRS network using the existing subscriber profiles and current network interfaces. 

A similar figure to Figure 6-1 is illustrated in Figure 6-4. Notice that it also leaves the current GPRS specifications 
mainly untouched whereupon the UMTS core network acts towards the GSN like a GSN by providing for example Gn. 
Further, it should be observed that GPRS subscriptions belong to the HLR whilst UMTS subscriptions exist in the HLR 
release 99. 
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UTRAN 



BSS 



2G-GGSN 




Figure 6-4: Inter-Operability between GSNs and UMTS 

Note: No physical implementation should be taken from Figure 6-4. As a further note, no interworking functions are 
shown to ease clarity, but however should not be precluded. 

From Figure 6-4 it can be seen that to provide inter-working between legacy packet switched and UMTS packet 
switched services, the information exchanged over the lu must provide the necessary parameters to enable the core 
networks to communicate via for example the Gn interface for handover purposes. 

Also note that from the above diagram, the same principles are used as in the circuit switched services to provide 
seamless roaming. 

6.2.1 Implications 

• The active PDP context resides in the same GGSN even after a handover between GSM and UMTS (both 
directions). This corresponds in principle to the anchor concept on the circuit switched side, but note that 
whereas packet sessions are long lived, the anchor MSC remains only for the duration of a CS call (typically 
much shorter than a packet session). 

• Assuming an internal structure in UMTS CN that contains logical GGSN and SGSN nodes, the signalling over 
the inter-system GGSN-SGSN interface should be a joint evolution of Gn for the GSM system and UMTS. I.e., 
when Gn evolves in the sequence of GSM releases, Gn should include any new or updated information necessary 
for interoperation. 

• The corresponding SGSN-SGSN inter-system interface (also Gn) should also be evolved together. However, in 
this case the changes relative to the current GPRS release may possibly be more profound. 

6.2.2 Signalling procedures 

The signalling procedures shows how handover UMTS <-> GSM GPRS can be done. The parameters carried by each 
message is not complete and shall be seen as examples of important information carried be the messages. 

The signalling sequences shows the case when the UMTS 3G_SGSN and the GPRS 2G_SGSN are located in separate 
"physical" nodes. 

If the 3G_SGSN and 2G_SGSN are located within the same "physical" node, no signalling are needed between 
3G_SGSN and 2G_SGSN. 
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For handover in the UMTS to GSM GPRS direction the intention is to re-use the handover principles of GSM GPRS 
today in order to Umit the changes in GSM GPRS and to take the changes if any on the UMTS side. The below 
specified messages is standard GSM 2+ messages (when applicable) 



6.2.2.1 
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n to 
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Figure 6-5: UMTS to GSM GPRS, Inter SGSN Routing Area Update Procedure 

1) The UE [2] or UTRAN [2] decides to perform handover which leads to that the UE switch to the new cell 

under the new system. 
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2) The UE sends a Routing Area Update Request (old RAI, old P-TMSI) to the new 2G_SGSN. The BSS shall 
add the Cell Global Identity including the RAC and LAC of the cell where the message was received before 
passing the message to the 2G_SGSN. 

3) The new 2G_SGSN sends SGSN Context Request (old RAI, old P-TMSI, New SGSN Address) to the old 
3G_SGSN to get the MM and PDF contexts for the UE (The old RAI received from the UE is used to derive 
the old 3G_SGSN address). 

4) Old 3G_SGSN sends SRNS Context Request to SRNS in order to receive the GTP-PDU sequence numbers 
of the GTP-PDUs to be next sent between UE and GGSN. SRNS responds with SRNS CONTEXT 
RESPONSE including the GTP_PDU sequence numbers and sequence numbers of last successfully received 
UL RLC-PDUs. 

5) The old 3G_SGSN responds with SGSN Context Response (MM Context, e.g. IMSI, PDP Contexts, e.g. 
APN). 

6) Security functions may be executed. 

7) The new 2G_SGSN sends an SGSN Context Acknowledge message to the old 3G_SGSN. This informs the 
old 3G_SGSN that the new 2G_SGSN is ready to receive data packets belonging to the activated PDP 
contexts. 

8) Old 3G_SGSN sends lu Release Command to SRNS. In case of lossless handover this message indicates the 
IP address to be used to return the unsent DL GTP-PDUs. Upon reception of this message the SRNS starts 
to return GTP-PDUs to old 3G_SGSN. SRNS responds with lu Release Complete. 

9) The new 2G_SGSN sends Update PDP Context Request (new SGSN Address) to the GGSN concerned. The 
GGSN update their PDP context fields and return Update PDP Context Response. 

10) The new 2G_SGSN informs the HLR of the change of SGSN by sending Update GPRS Location (SGSN 
Number, SGSN Address, IMSI) to the HLR. 

11) The HLR sends Cancel Location (IMSI) to the old 3G_SGSN. The old 3G_SGSN removes the MM and 
PDP contexts. 

The old 3G_SGSN acknowledges with Cancel Location Ack (IMSI). 

12) The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new 2G_SGSN. The 
2G_SGSN constructs an MM context for the UE and returns an Insert Subscriber Data Ack (IMSI) message 
to the HLR. 

13) The HLR acknowledges the Update Location by sending Update GPRS Location Ack (IMSI) to the new 
2G_SGSN. 

14) The new 2G_SGSN validates the UE's presence in the new RA. The new 2G_SGSN constructs MM and 
PDP contexts for the UE. A logical link is established between the new 2G_SGSN and the UE. To avoid 
data duplication the sequence numbers of the RLC link that was used before the handover may be used to 
initialise the logical link. The new 2G_SGSN responds to the UE with Routeing Area Update Accept 
(P-TMSI). 

15) The UE acknowledges the new P-TMSI with a Routing Area Update Complete (P-TMSI). 
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6.2.2.2 Handover from GSM GPRS to UMTS 



UE 



1. Deciskm tq)erform I 



Setup radio 



2. x_Routing Area 



4. Security 



BSS SRNS 



^.x_Roating Area Update 



13.x_Roating Area Update 



new 
3G SGSN 



Update 



5. RAB Ass ignment Reque st 



5. RAB A|s ignment Response 



old 
2G SGSN 



3. SGSN Context 



4 



SGSN Context 



^nment ] 

). SGSN Context 



Note 1 



7. Update PD ^ Context 



X Update PD ^^ Context 



8. Update GP ^S 



^ 



. Insert Subscriber 



GGSN 



Cancel 



9. Cancel 



10. Insert Subscriber Ack 



y. Update G^RS Ac e 



HLR 



Ack 



Figure 6-6: GSM GPRS to UMTS, Inter SGSN Routing Area Update Procedure 

1) The UE/network decides to perform handover which leads to that the UE switch to the new cell, details for 
this is FES. 

2) The UE sends a x_Routing Area Update Request (old RAI, old P-TMSl) to the new 3G_SGSN. The SRNS 
shall add an identifier of the area where the message was received before passing the message to the 
3G_SGSN. 

3) The new 3G_SGSN sends SGSN Context Request (old RAI, old P-TMSI, New SGSN Address) to the old 
2G_SGSN to get the MM and PDF contexts for the UE (The old RAI received from the UE is used to derive 
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the old 2G_SGSN address). The old 2G_SGSN responds with SGSN Context Response (MM Context, e.g. 
IMSI, PDP Contexts, e.g. APN). 

4) Security functions may be executed. 

5) The new 3G_SGSN request the SRNS to establish of a radio access bearer by sending RAB Assignment 
Request to the SRNS. The SRNS responds with RAB Assignment Response. 

6) The new 3G_SGSN sends an SGSN Context Acknowledge message to the old 2G_SGSN. This informs the 
old 2G_SGSN that the new 3G_SGSN is ready to receive data packets belonging to the activated PDP 
contexts. 

7) The new 3G_SGSN sends Update PDP Context Request (new SGSN Address) to the GGSN concerned. The 
GGSN update their PDP context fields and return Update PDP Context Response. 

8) The new 3G_SGSN informs the HLR of the change of SGSN by sending Update GPRS Location (SGSN 
Number, SGSN Address, IMSI) to the HLR. 

9) The HLR sends Cancel Location (IMSI) to the old 2G_SGSN. The old 2G_SGSN removes the MM and PDP 
contexts. 

The old 2G_SGSN acknowledges with Cancel Location Ack (IMSI). 

10) The HLR sends Insert Subscriber Data (IMSI, GPRS subscription data) to the new 3G_SGSN. The 

3G_SGSN constructs an MM context for the UE and returns an Insert Subscriber Data Ack (IMSI) message 
to the HLR. 

1 l)The HLR acknowledges the Update GPRS Location by sending Update Location Ack (IMSI) to the new 
3G_SGSN. 

I2)The new 3G_SGSN validates the UE's presence in the new RA. The new 3G_SGSN constructs MM and PDP 
contexts for the UE. A logical link is established between the new SGSN and the UE. The new 3G_SGSN 
responds to the UE with x_Routing Area Update Accept (P-TMSI). 

13)The UE acknowledges the new P-TMSI with a x_Routing Area Update Complete (P-TMSI). 

Note 1: The functionality for forward of packets and handling of GTP sequence numbers (within the box) is a subject 
fore more investigation, i.e. FFS. The GPRS principles should apply. 



Annex A (Informative)Reduction of UMTS signalling 

A. 1.1 GLR Concept 

The benefit of the Gateway Location Register (GLR) is the reduction in signalling traffic between networks. GLR is an 
optional network element which shall not affect the MAP protocol. 

A.1.1.1 Overview of the GLR Concept 

The GLR is a node between the VLR and the HLR, which may be used to optimise the handling of subscriber location 
data across network boundaries. 

In Figure 1, the GLR interacts with HLRa and VLRb for roamers on Network B. The GLR is part of the roaming 
subscriber's Home Environment. When a subscriber to HLRa is roaming on Network B the GLR plays the role of an 
HLR towards VLRb and the role of a VLR towards HLRa. The GLR handles any location change between different 
VLR service areas in the visited network without involving HLRa. 
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Network A 



Network B 




Figure A.I : GLR Overview 

The sequence of events when the subscriber roams to network B is as follows: 

• VLRb sends the registration message to HLRa via the GLR, (i.e. HLRa stores the GLR's SCCP address and the 
GLR stores VLRb's SCCP address). 

• HLRa returns the subscriber profile data 

• The subscriber profile is stored in the GLR and VLRb 

As the roaming subscriber moves between VLRs in network B, then the GLR is updated, but no message is sent to 
HLRa, therefore the number of messages between Network A and Network B is reduced. The reduction in signalling 
traffic is a significant benefit when the two networks are far apart, e.g. between Europe and Japan. 
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